AD-A229  423 


DTIC 

ELECTE  M 
DEC12 19901  ■ 

E  ^ 


DEPARTMENT  OF  THE  AIR  FORCE 
AIR  UNIVERSITY 

AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 


Wrighf-Patterson  Air  Force  Base,  Ohio 


distribution  STATEH/gWT  A 

Approved  for  pubhc  release; 
Disliibution  Unlimited 


0‘'\ 

:  * 


1  R 


AFIT/GIW/LSM/90S-44 


AOTCWATING  ESTABLISHMENT  MANAGEMENT 
FOR  TOE  RAAF  MOTOR  TRANSPORT  FLEET: 
A  MICROCOMPUTOR 
DATABASE  APPLICATION 

THESIS 

Robert  T.  Quirk 
Flight  Lieutenant,  RAAF 

AFIT/GD4/Lai/90S-44 


Approved  for  public  release;  distribution  unlimited 


The  opinions  and  conclusions  in  this  paper  are  those  of  the 
author  and  are  not  intended  to  represent  the  official 
position  of  the  DOD,  USAF,  or  any  other  government  agency. 


Accession  7or 

jlTIS  GRA&I 
DIIC  TAB 

Unannounced 

Justification. 


By- 

Distrysutlon/ 

\  lability  Codes  ^ 

- ^vall  and/or  ^ 


Dlst 


m 


Special 


AFIT/GLM/LSM/90S  -44 


AUTOMATING  ESTABLISHMENT  MANAGEMENT 
FOR  THE  RAAF  MOTOR  TRANSPORT  FLEET: 
A  MICROCCWPllTER 
DATABASE  APPLICATION 


THESIS 


Presented  to  the  Faculty  of  the  School  of  Systems  and  Logistics 
of  the  Air  Force  Institute  of  Technology 
Air  university 

In  Partial  Fulfillment  of  the 
Requirements  for  the  Degree  of 
Master  of  Science  in  Logistics  Management 


Robert  T.  Quirk,  B.Bus. 
Flight  Lieutenant,  RAAF 


September  1990 


Approved  for  public  release;  distribution  unlimited 


Preface 


The  purpose  of  this  study  was  to  research  the  requirements  for,  and 
develop,  a  microconputer  based  database  application  to  automate 
establishment  management  of  the  Royal  Australian  Air  Force  (RAAF)  motor 
transport  (MT)  fleet  at  the  Directorate  of  Movement  and  Transport  Air 
Force  (EMOVT-AF) .  This  application  was  assessed  by  IM)VT-AF  as  the 
priority  module  for  development  as  part  of  a  larger  management 
information  system  (MIS)  for  RAAF  MT  assets. 

This  research  selected  systems  analysis  tools  and  the  most 
appropriate  software,  determined  user  requirements,  developed, 
evaluated,  and  validated  a  prototype  system.  The  resulting  software 
application,  the  MT  Establishment  Management  Information  System  (ESTAB), 
met  user  requirements,  improved  efficiency,  and  accuracy  of  MT 
establishment  management  at  EMOVT-AF.  ESTAB  integrates  data  from 
various  sources  and  provides  the  ability  to  add,  edit,  and  report  MT 
establishment  information. 

This  research  is  just  the  beginning  of  providing  automated 
information  support  for  the  management  of  RAAF  MT  assets.  Additional 
research  should  continue  to  build  on  the  ESTAB  database  and  application 
to  reap  greater  efficiency  and  productivity  benefits  for  the  RAAF. 

In  performing  this  research  and  writing  this  thesis,  I  had  a  great 
deal  of  help  from  others.  I  especially  wish  to  thank  a  few  people. 
Thanks  to  my  thesis  advisor.  Major  Phil  Beard,  for  giving  me  direction 
and  encouragement,  and  introducing  me  to  the  advanced  programming  tools 
available  for  database  applications.  This  thesis  would  not  have  been 
possible  but  for  my  Australian  connection.  I  wish  to  thank  Squadron 
Leader  Pete  Haren  for  his  assistance  and  patience  through  this  marathon. 
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Finally,  I  wish  to  express  my  thanks  to  my  wife  Kristina  and  dedicate 
this  thesis  to  her.  I  would  not  have  been  able  to  spend  the  time  and 
effort  to  produce  this  work,  if  not  for  her  constant  understanding  and 
support.  Thanks  KQ! 


Robert  T.  Quirk 
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Abstract 

Itie  purpose  of  this  study  was  to  research  the  requirements  for, 
and  develop,  a  microcomputer  based  database  application  to  autanate 
establishment  management  of  the  Royal  Australian  Air  Force  (RAAF)  motor 
transport  (MT)  fleet  at  the  Directorate  of  Movement  and  Transport  Air 
Force  (DMOVT-AF) .  This  application  was  assessed  as  the  priority  module 
for  development  by  DMOVT-AF  as  part  of  a  larger  management  information 
system  (MIS)  for  RAAF  MT  assets. 

This  research  selected  systems  analysis  tools  and  the  most 
appropriate  softv;are,  determined  user  requirements,  developed,  evaluated 
and  validated  a  prototype  system.  The  resulting  software  application, 
the  Motor  Transport  Establishment  Management  Information  System  (ESTAB), 
met  user  requirements,  improved  efficiency,  and  accuracy  at  DMOVT-AF. 

It  was  designed  to  operate  on  IBM  compatible  personal  computers  in 
accordance  vhth  Australian  Department  of  '  efence  DESINE  standards. 

ESTAB  integrates  data  from  various  sources  and  provides  the  ability  to 
add  edit,  and  report  motor  transport  establishment  information. 
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AUTCMATING  ESTABLISHMENT  MANAGEMENT 


EOR  TOE  RAAF  MOTOR  TRANSPORT  ElEET: 
A  MICSOCCMPLflER 
DATABASE  APPLICATION 


I.  Introduction 


Background 

The  objective  of  the  Australian  Defence  Force  (ADF)  is  to 

plan,  develop  and  maintain  forces  for  contingencies  within 
Australia's  area  of  direct  military  interest,  to  defend 
Australia  and  its  interests  at  sea,  on  land  and  in  the  air, 
or  any  conbination  of  these  (Commonwealth  of  Australia, 

1988:1) . 

The  Royal  Australian  Air  Force  (RAAF)  Manual  of  Motor  Transport 
operations  states  that 

for  the  RAAF  to  fulfil  its  commitments  within  the  ADF,  the 
RAAF  requires  a  well  balanced  fleet  of  modern  general 
purpose  and  special  purpose  vehicles  appropriate  to  its 
operational  and  administrative  needs  (Department  of  Defence, 
1989a:l) . 

The  RAAF  allocates  specific  numbers  and  types  of  vehicles 
considered  necessary  for  efficient  daily  functions  to  individual  RAAF 
units. 


RAAF  Motor  Transport  Asset  Management 

Asset  management  of  the  RAAF  motor  transport  (MT)  fleet  is  divided 
between  three  levels;  Directorate  of  Movements  and  Transport  -  Air  Force 
(EMOVT-AF),  Support  Group  3  (SG3)  and  Road  Movements  Sections  (RMS). 


IM)VT-AF.  The  highest  level  of  management  of  the  RAAF  MT  fleet 
is  vested  in  the  EMDVT-AF,  Air  Force  office.  As  the  fleet  controller, 
IM)VT-AF  is  responsible  for  administering  the  RAAF  MT  Establishment 
Tables  which  reflect  authorised  allocations  of  vehicles. 

SG3.  SG3  of  Headquarters  RAAF  Logistics  Ccanmand  is  responsible 
for  daily  fleet  managanent  activities  including  allocation  of  resources 
against  establishment  tables,  and  acquisition  and  disposal  directions 
for  fleet  vehicles. 

Base  RMS.  RMS  are  responsible  for  managing  and  allocating 
vehicles  at  the  Base  level.  The  typical  Base  RMS  is  divided 
functionally  into  four  areas:  Aircraft  Refueling,  Vehicle  Despatch, 
Licencing  and  Trade  Testing,  and  Administration.  The  Aircraft 
Refuelling  function  is  responsible  for  providing  aviation  fuel  to  home 
based  and  transit  aircraft.  The  vehicle  Despatch  function  is 
responsible  for  the  allocation  of  vehicles  to  meet  ad  hoc  and  scheduled 
tasks.  The  Trade  Testing  function  is  responsible  for  testing  and 
administering  Service  driving  licence  requirements  for  all  RAAF  and 
civilian  members  on  that  Base.  The  Administration  function  is 
responsible  for  issuing  petrol,  oils  and  lubricants  (POL),  maintaining 
vehicle  data,  ensxiring  serviceability  of  all  vehicles,  and  providing 
administrative  support  to  the  Vehicle  Despatch  function.  Tbe 
Administration  function  manually  manipulates  and  maintains  all  Base  MT 
vehicle  despatch,  vehicle  use,  and  administrative  data.  Aggregated  data 
for  the  management  of  the  vehicle  fleet  is  manually  transmitted  yearly 
to  DMOVT-AF  and  to  SG3.  IM)VT-AF  maintains  ITT  establishment  tables  on  a 
microcCTiputer  in  word-processing  format  with  a  UNIX^**  operating  system. 
Ttiis  information  is  manually  maintained  at  other  levels.  SG3  maintains 
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a  database  of  vehicle  data  under  AlphaBasic^**  on  a  Alphamicro^**  conputer. 
This  system  is  expected  to  be  enhanced  for  use  on  an  NCR  Unijr^  based 
local  area  network-  IMDVT-AF  reviews  Base  vehicle  allocations  on  an  ad 
hoc  basis  using  sample  data  provided  from  manual  Base  RMS  records.  Ttiis 
information,  coupled  with  user  mission  requirements,  is  used  to  verify 
vehicle  establishments. 

DESINE .  The  Defence  Electronic  Data  Processing  (EDP)  Systems 
Integrated  Netwrk  Environment  (DESINE)  project  will  provide  the 
Department  of  Defence  with  a  standard  information  systems  architecture 
for  the  next  five  years  (Caranonwealth  of  Australia,  1988:67).  Under 
this  project  a  greater  number  of  microcomputers  will  be  available 
throughout  the  RAAF.  This  provides  a  unique  opportunity  to  implement 
microcomputer  based  management  support  systems.  Before  the  adoption  of 
the  DESINB  standard,  the  ADF  postponed  many  small  computer  projects  to 
reduce  future  computer  hardware  inccanpatibility  problems. 

Despite  the  increasing  availability  of  computer  hardware  there  is 
no  comprehensive  management  information  system  (MIS)  that  links  the 
ccxnmon  data  requirements  for  IM3VT-AF,  SG3,  and  Base  RMSs.  The  RAAF 
maintains  data  for  the  RAAF  surface  vehicle  fleet  on  a  variety  of  manual 
and  ccmputerised  information  systems  with  data  gathered  from  several 
organisations  and  publications.  Current  techniques  are  inefficient  and 
cumbersome.  Commercial ly  available  and  government  developed  software 
systans  are  unsuitable  for  RAAF  NfT  management  needs.  The  E?MF  requires 
a  tailor-made  MT  MIS  to  improve  MT  management  efficiency  at  I>10VT-AF 
(Department  of  Defence,  I988:xi). 

DMOVT-AF's  current  vjord-processing  and  SG3's  current  systems  are 
implemented  on  microcomputer  systems  that  fail  to  conform  with  DESINE 
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standards  and  will  be  unable  to  communicate  with  future  systems. 

As  the  establishment  tables  drive  other  elements  of  the  asset 
management  system,  autcanation  of  this  area  will  have  the  highest 
priority  in  development  of  an  MIS  (Haren,  1989;  Miller,  1989). 

Specific  Problem 

The  problem  is  to  define  the  requirements  for,  develop,  and 
evaluate  a  prototype  microcomputer  database  application  vAiich  will 
improve  efficiency  in  data  processing  and  management  of  the  RAAF  MT 
fleet  establishment  at  DMOVT-AF. 

Research  Questions 

To  enable  development  of  an  application  to  improve  the  efficiency 
of  RAAF  MT  establishment  management  the  following  questions  must  be 
answered: 

1.  Is  a  database  application  suitable  for  improving  the 
efficiency  of  RAAF  MT  asset  management? 

2.  Which  are  the  most  appropriate  systems  analysis  and  softvrare 
techniques  for  developing  a  database  application? 

3.  What  are  the  data  processing  and  information  requirements  for 
executive  level  RAAF  MT  asset  management? 

4.  Which  data  processes  and  information  requirements  can  be 
improved  by  using  a  microcomputer  database  application? 

5.  Can  appropriate  computer  programs  be  generated  to  meet  those 
user  requirements  assessed  as  being  most  appropriate  for  automation? 

6.  Hcv/  can  the  application  be  validated  to  ensure  successful 
implementation  and  acceptance  by  users? 
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7.  Does  the  proposed  system  provide  improvements  in  efficiency 


\*jhen  cOTipared  with  current  managanent  practices? 

Scope  of  the  Thesis 

A  management  information  system  can  be  described  as  a 
canputer -based  information  processing  system  designed  to  support 
operations,  management,  and  decision  support  functions  of  an 
organisation  (McClave  and  Benson,  1988:  955).  This  thesis  will  result 
in  a  microccanputer  database  application  for  use  at  EMOVT-AF  with  an 
accompanying  user's  manual.  This  thesis  will  not  deal  with  specific 
programming  techniques  except  where  explanation  is  necessary  to  ensure 
adequate  documentation  for  future  program  modifications  and  additions. 

Limitations 

Time  limits  the  scope  of  this  thesis.  An  ideal  MIS  for  the 
management  of  RAAF  MT  assets  wuld  incorporate  information  requirements 
from  all  levels  of  management  within  the  Service  and  may  even 
incorporate  requirements  for  ADF-wide  management  of  surface  vehicle 
assets.  This  thesis  will  only  address  the  problems  associated  with 
information  management  at  the  executive  level  of  the  RAAF,  namely 
DMC3VT-AF. 

Assumptions 

The  following  assumptions  af^ly  for  the  purposes  of  this  study: 
future  RAAF  microcomputer  systems  are  International  Business  Machine 
(IBM)  compatible  in  accordance  with  implementation  of  the  DESINE 
Project;  the  responsibilities  and  methods  for  determining  vehicle 
establishments  v/ill  not  change  dramatically  in  the  future;  and  the  basic 


MT  management  structure  will  also  remain  stable. 

Organisation  of  the  Thesis 

This  thesis  is  divided  into  five  chapters  and  five  appendices. 
Chapter  I  introduces  and  details  the  background  of  the  problem, 
including  RAAF  MT  management  structure  and  data  requirements,  a  specific 
problem  statement,  research  questions,  scope  and  limitations  of  the 
thesis  plus  any  assumptio.is  made  to  produce  the  thesis. 

Chapter  II  contains  a  literature  review  that  attempts  to  answer 
research  questions  one  and  two.  It  can  be  divided  into  three  main 
areas:  prior  ADF  and  United  States  Air  Force  (USAF)  studies,  information 
systems  analysis  and  design,  and  databases  and  database  management 
systems . 

Chapter  III  describes  the  investigation  of  the  problan,  and  uses 
the  chosen  systems  analysis  and  design  methodologies  to  produce  the 
appl i cat ion. 

Chapter  IV  compares  the  application  against  the  user  requirements 
and  answers  research  questions  3  through  7  posed  in  Chapter  I. 

Chapter  V  provides  a  summary  of  the  thesis,  reccmmendations, 
conclusions,  and  a  list  of  suggested  follcw-on  studies. 

Appendices  provide  the  application  documentation.  Appendix  A 
contains  the  target  document.  Appendix  B  is  the  data  dictionary  used 
throughout  the  thesis  and  incorporated  within  the  application. 

;^3pendix  C  is  the  entity  attribute  list  of  the  database  for  the 
application.  Appendix  D  is  the  ESTAB  application  User  Manual.  Appendix 
E  is  the  total  MT  MIS  entity  relationship  diagram.  TWo  5.25  inch 
computer  disks  contain  the  source  code  of  the  programs  that  make  up  the 


6 


ESTAB  application.  Another  5.25  inch  disk  contains  the  installation 
program  which  includes  the  executable  ESTAB  application  and  associated 
databases . 


7 


II.  Literature  Review 


Chapter  Overview 

The  purpose  of  this  chapter  is  to  answer  research  questions  one 
and  two  fran  chapter  I.  The  first  half  of  the  chapter  will  provide  the 
reader  with  an  overview  of  previous  studies  undertaken  by  the  ADF  and 
the  USAF.  This  is  followed  by  a  discussion  of  databases,  database 
management,  systems  analysis  and  specification  methodologies,  and 
software  suitable  for  the  task. 

Research  Question  One 

Is  a  database  application  suitable  for  improving  the 

efficiency  of  RAAF  KT  asset  management? 

A  review  of  previous  studies  undertaken  by  the  ADF  and  the  USAF 
into  methods  for  improving  the  managaa[ient  of  MT  assets  suggests  a 
database  application  would  be  suitable  for  improving  the  efficiency  of 
RAAF  MT  assets. 

Prior  ADF  Studies 

BSMART.  Recognition  of  the  need  for  conputer-based  assistance  for 
management  of  supply  related  activities  resulted  in  a  project  called  the 
"Base  Supply  Management  and  Running  Transport"  (BSMART)  system  vSiich 
commenced  in  1985.  The  project's  concept  centered  on  capturing  relevant 
statistical  data  at  the  Icwest  management  level  and  aggregating  it  for 
higher  levels  of  management.  The  Directorate  of  Supply  Computing  -  Air 
Force  (DSC-AF)  developed  two  prototypes  of  the  system  and  a  working 
model  of  the  unit  level  for  Air  Force  use.  One  of  the  secondary 
functions  of  the  project  was  to  provide  a  transport  fleet  management 
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package  at  each  ion it  to  assist  in  scheduling  vehicle  usage  and 
maintenance  (Department  of  Defence,  1988b). 

Unfortunately,  the  goals  of  the  BSMART  system  were  never  fully 
realised  due  to  financial  constraints.  Hie  non-transport  aspects  of  the 
system  implemented  at  RAAF  Stores  Depots  have  new  fallen  into  disuse 
(Haren,  1989).  The  MT  aspects  of  BSMART  would  have  relieved  sane  of  the 
repetition  from  RMS  management  activities  vrfiile  allowing  greater 
management  visibility  of  many  functions  including  the  use  of  all  MT 
assets. 

Defence  Commercial  Vehicle  Review.  Concern  over  increasing  costs 
associated  with  managing  and  maintaining  private  vehicle  fleets  within 
the  ADF,  and  the  reduction  in  funds  allocated  for  this  purpose,  led  to 
investigation  of  new  management  practices  at  all  management  levels.  In 
1988,  the  Department  of  Defence  appointed  Pak-Poy  and  Kneebone  with 
Henderson  Consultants  to  undertake  a  three  phase  investigation  designed 
to  improve  the  cost  effectiveness  of  the  Defence  Commercial  Line  (CL) 
vehicle  fleet.  The  subsequent  report  stressed  the  requirement  for 
greater  amounts  of  accurate  and  timely  vehicle  data  for  decisions 
concerning  all  aspects  of  operations  (Pak-Poy  and  others,  1988:75). 
Highlighted  for  special  attention  was  optimising  vehicle  resale  values 
at  disposal.  Specifically,  the  consultants'  report  recognised  the  need 
for  a  fleet  MIS  to  enhance  the  management  effectiveness  and  efficiency 
in  this  area.  The  report  evaluated  commercially  available  and 
government  developed  software  systens  for  the  task,  but  found  them 
better  suited  to  private  companies  as  they  did  not  fully  meet  Defence 
needs.  A  tailor-made  MIS  would  need  developing  either  in-house  or  by  a 
civilian  contractor  (Pak-Poy  et  al .  I988:x-xi).  The  operation  of  a 
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fleet  MIS  requires  uniformity  across  all  users.  The  report  reconmended 
introducing  an  ADF-wide  system  to  be  managed  by  the  Royal  Australian 
Navy  (RAN)  for  the  other  two  Services.  Subsequent  discussion  within  the 
Department  of  Defence  and  between  the  RAN,  Australian  Army,  and  RAAF  led 
to  the  specification  of  seme  tri-Service  requirements  for  an  MT  MIS. 

The  discussion  produced  a  decision  that  management  of  all  aspects  of  the 
Services'  fleets  would  remain  with  the  individual  Services.  Requests 
for  tender  for  the  supply  of  computer  support  for  acquisition  and 
disposal  of  RAAF  CL  vehicles  are  being  prepared.  This  process  will  take 
some  time  to  complete  and  will  only  account  for  a  small  element  of  the 
total  fleet  MIS  requirements  for  the  RAAF  (Haren, 1989) . 

USAF  Vehicle  Asset  Management  Systems 

Obvious  similurities  exist  between  the  RAAF  and  USAF  concerning 
fleet  management  practices.  Both  systems  are  organised  on  approximately 
the  same  basis  with  vehicles  allocated  against  authorised  establishments 
based  on  mission  requirements  and  use.  A  support  group  is  tasked  in 
both  organisations  to  fulfill  the  establishments  and  forecast  future 
purchasing  requirements.  Experiences  within  the  USAF  regarding  the 
development  of  computer  based  support  for  the  management  of  vehicles 
should  therefore  be  of  seme  use  historically. 

The  USAF  has  enjoyed  the  use  of  microcomputers  for  some  years. 

Such  an  environment  has  led  to  the  development  of  several 
specif ic-to- type  asset  management  systans.  Some  of  these  systems  deal 
directly  with  elements  that  would  be  appropriate  to  RAAF  MIS 
applications  vrtiile  others  shov;  the  advantages  of  asset  management 
systems  in  the  military. 
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War  Reserve  Material  Vehicles.  First  Lieutenant  Robert  S.  Thomas, 
in  his  1988  AFIT  niesis,  A  Cmputer  Based  Data  Management  System  for  Air 
Force  War  Reserve  Material  (WRM)  Vehicle  Management,  acJdressed  the  lack 
of  ccxnputer  support  for  the  tasks  associated  with  the  managenent  of  the 
12,000  WBM  fleet  vehicles  positioned  throughout  Europe.  In 
circumstances  similar  to  the  RAAF  MT  asset  management  problon,  a  series 
of  reports  highlighted  the  need  for  more  accurate  and  timely  information 
on  the  disposition  of  MT  assets.  Attempts  were  made  to  provide 
additional  support  to  management,  but  delays  in  development  of  systems 
prompted  Thcmas  to  develop  a  microccmputer  based  system  for  transport 
personnel  managing  WRM  assets.  The  WRM  Vehicle  Management  System  uses 
database  software  to  provide  a  capability  for  vehicle 
dispersal/distribution  management,  release  case  managanent,  scheduled 
action  management,  and  a  variety  of  reports  for  all  or  subsets  of  the 
fleet  (Thonas,  1983). 

Vehicle  Master  Plan.  Another  AFIT  Thesis  produced  by  First 
Lieutenant  Hans  Garcia  in  1989,  titled  A  Computer  Based  Data  Management 
System  for  Autcmatinq  the  Air  Force  Vehicle  Master  Plan,  developed  a 
microcomputer  database  management  application  to  automate  the  labor- 
intensive  tasks  performed  by  vehicle  program  managers  at  Wamer-Robins 
Air  Logistics  Center.  This  organisation's  tasks  are  very  similar  to 
those  performed  by  SG3  in  the  RAAF.  The  programs  produced  by  Garcia  can 
be  used  to  provide  a  single  source  of  information  on  the  vehicle  fleet 
allowing  development,  justification,  and  ranking  of  vehicle  programs  to 
meet  USAF  vehicle  needs  (Garcia,  1989). 

Computer  Assisted  Transportation  System  (CATS).  The  Air  Force 
Logistics  Management  Center  (AFLMC)  develoF>ed  CATS  as  a  microcomputer 
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based  system  consisting  of  several  independent  modules  designed  to 
"improve  readiness  and  increase  productivity  and  efficiency"  at  base- 
level  vehicle  operations  (Department  of  the  Air  Force,  1988:182). 

One  module,  the  Vehicle  Asset  Management  System  (VAMS),  is  a 
ccxnplete  package  for  managing  vehicles  at  the  Base  level .  Apart  from 
assisting  with  administrative  tasks,  VAMS  automatically  reconciles  the 
On-Line  Vehicle  Interactive  Management  Systen  (OLVIMS)  information  with 
vehicle  authorisation  and  assignment  data. 

Another  module  is  a  driver  evaluation  system  developed  by  Captain 
James  Van  Scotter  in  1986.  While  outside  the  scope  of  this  thesis,  the 
Computer  Assisted  Transportation  System  Driver  Evaluation  System 
provides  important  insights  into  possible  applications  that  could  be 
included  in  a  complete  MT  MIS.  This  set  of  application  programs  was 
also  developed  for  use  on  microcomputers  using  a  database  language.  It 
is  aimed  at  helping  Base  management  increase  productivity  by  assisting 
with  the  management  of  vehicle  operator  qualifications,  vehicle  trainer 
qualifications,  lesson  plans,  accidents,  abuse  cases,  and  misuse  cases. 
It  generates  licenses  and  provides  tools  for  analysis  of  the  previously 
detailed  areas  (Van  Scotter,  1986:  1). 

Another  system  to  assist  with  vehicle  management  is  the  Priority 
Buy  (PRIBUY)  systan.  The  USAF  Standard  Systems  Center  (SSC)  developed 
PRIBUY  to  assist  major  USAF  commands  develop  annual  priority  purchase 
submissions.  This  system  is  also  microcomputer  based. 

SSC  is  also  developing  the  OLVIMS  system  to  improve  handling 
procedures  and  management  of  the  vehicle  maintenance  activity.  The 
first  of  three  stages  of  this  system  is  complete  and  allows  interactive 
data  entry  and  edit  capabilities  on  a  mainframe  computer.  The  next 
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stage  will  make  a  transition  to  microccxnputers  frcxn  the  mainframe  while 
stage  three  plans  to  provide  the  capability  to  automate  work  orders 
(Department  of  the  Air  Force,  1988:182). 

Vehicle  Operations  Automation.  In  June  1988,  additional 
autcmation  requirements  for  Base-level  transportation  management  were 
identified  by  AFI/C  in  another  report  by  Van  Scotter  titled  Vehicle 
Operations  Automation  Requirements  Document  (Van  Scotter,  1987b) .  The 
report  outlines  the  functional  requirements  for  computer  systems  in 
three  base-level  vehicle  operations  activities:  driver  evaluation, 
vehicle  asset  management,  and  fleet  utilisation  and  cost  reporting.  In 
compiling  the  report,  AFLMC  studied  previous  projects  to  determine  the 
limitation  of  existing  software  in  these  areas.  The  document  provides  a 
checklist  for  elements  to  be  considered  in  any  military  fleet  MIS,  but 
only  those  elements  dealing  with  asset  management  will  be  considered  in 
this  thesis. 

Other  Military  Database  Management  Systems .  Many  other 
microcomputer  database  applications  have  been  developed  for  specific 
uses  within  the  USAF.  The  ability  to  develop  and  introduce  these 
systems  quickly  has  resulted  in  solutions  that  otherwise  may  have  taken 
many  years  to  achieve  via  normal  Service  systems  development  cycles. 

The  common  availability  of  microcomputers  within  the  U^AF  work 
environment  has  provided  a  fertile  environment  for  the 
development  of  these  applications.  The  future  availability  of 
microcomputers  throughout  the  ElAAF  v/iJl  provide  the  catalyst  for  the 
production  of  many  similar  prototypes  and  functional  applications.  The 
arrival  of  the  RAAF  Base  Squadron  Administrative  Computer  Systan  (BSACS) 
at  Base  level  and  the  introduction  of  microcomputers  at  higher  command 
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levels  heralded  a  new  era  in  computer  support  for  management  in  the  RAAF 
in  1988.  However,  the  proliferation  of  the  hardware  highlighted  the 
need  for  developed  applications  to  make  full  use  of  each  microccntputer 
system's  potential.  Itie  investigator  witnessed  that  with  many  users 
untrained  in  programming  skills,  systems  did  not  provide  expected 
benefits.  Applications  were  developed  piecemeal  at  various  locations 
and  implojvented  without  precise  systons  analysis  or  design.  Poorly 
developed  software  and  database  design  can  produce  maintenance  problems 
that  could  plague  the  organisation  for  many  years.  Any  failure  to 
provide  applications  for  current  and  future  RAAF  microcomputer  assets 
means  that  existing  inefficiencies  will  continue.  Expected  productivity 
increases  over  manual  practices  also  will  not  be  realised. 

Databases  and  Database  Management 

"Database  technology  facilitates  the  production  of  information. 

The  fundamental  purpose  of  all  information  systems  is  to  reduce 
uncertainty"  (Kroenke  and  Dolan,  1988:25).  The  reduction  in  computer 
hardware  costs  and  increasing  labor  costs  make  the  adoption  of  computer 
systans  attractive  for  many  organisations.  Database  processing 
transfers  the  workload  from  people  within  an  organisation  and  places  it 
upon  the  hardware  while  substantially  increasing  the  productivity  of 
users  (Kroenke  and  Dolan,  1988:9,  xvii).  Database  technology  was 
developed,  to  a  great  degree,  to  overcome  the  limitations  associated 
with  file  processing  systems.  A  database  application,  therefore, 
provides  many  advantages  over  traditional  file  management  techniques 
(Kroenke  and  Dolan,  1988:9). 
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Databases .  A  database  may  be  defined  as  a  collection  of 


interrelated  data  stored  together  (Martin,  1977:23).  Databases  provide 
the  following  functions  v^iich  allow  maintenance  and  manipulation  of  data 
more  efficiently,  effectively,  and  safely  than  prior  to  their 
development: 

a.  data  can  be  entered  and  stored  efficiently  with  little  or  no  harmful 
redundancy, 

b.  data  can  be  protected  with  error-checking  and  consistency-checking 
functions, 

c.  data  can  be  protected  frcmi  unauthorised  access, 

d.  the  impact  of  software  errors  can  be  reduced, 

e.  data  can  be  maintained  independent  of  applications  that  use  the 
data,  and 

f.  current  data  can  be  maintained  in  a  central  location  for  use  by  many 
applications  (Martin,  1977:22-23:  Banet  et  al,  1985:5). 

The  structure  of  a  database  consists  of  characters,  fields, 
records,  and  files.  Raw  data,  represented  as  characters,  are  grouped 
into  a  field  or  fields  to  form  a  single  piece  of  information,  such  as  a 
vehicle  registration  number.  Several  fields  or  attributes  are  grouped 
as  a  record  to  represent  information  about  an  entity  or  an  object.  A 
file  is  a  collection  of  records  (Martin,  1977:  48-52;  Wray,  1988:7). 

A  database  is  also  called  a  "self-describing  collection  of 
integrated  records"  (Kroenke  and  Dolan,  1988:11).  This  data  self¬ 
description  is  achieved  through  the  data  dictionary  and  a  description  of 
the  relationships  between  the  data  elements  in  the  records.  The  data 
dictionary  provides  a  description  of  the  structure  of  the  database  and 
makes  program  independence  with  database  processing  possible  (Kroenke 
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and  Dolan,  1988:11).  Program  independence  allows  development  of  many 
applications  for  the  same  database  without  the  programmer  needing  to 
consider  the  physical  storage  format  of  the  data  (Martin,  1977:28).  The 
data  dictionary,  as  an  important  documentary  tool,  will  be  discussed  in 
greater  detail  later  in  this  chapter.  The  relationship  descriptions  are 
stored  and  recalled  during  the  processing  of  the  database  (Kroenke  and 
Dolan,  1988:13). 

Database  Types.  Based  on  representation  of  data  relationships, 
there  are  three  types  of  databases:  hierarchical,  network,  and 
relational.  "The  combination  of  microccanputers  and  the  relational  model 
present  some  tremendous  opportunities  in  end-user  database  processing" 
(Kroenke  and  Dolan,  1988:23).  Relational  databases  are  the  most  common 
type  in  use  today.  One  of  the  main  advantages  relational  databases  have 
over  other  types  of  data  organisation  is  that  relational  data  models,  at 
least  conceptually,  store  data  in  a  manner  that  users  can  understand 
(Kroenke  and  Dolan,  1988:21). 

Relational  databases  use  two-dimensional  tables  to  represent  data 
and  relationships  (Martin,  1977:202-203).  These  tables  or  rectangular 
arrays  can  be  described  mathematically  as  relations  with  the  follov/ing 
properties: 

1.  Each  entry  in  a  table  represents  one  data  item;  there  are  no 
repeating  groups. 

2.  They  are  column-honogeneous;  that  is,  in  any  column  all  items 
are  of  the  same  kind. 

3.  Each  column  is  assigned  a  distinct  name. 

4.  All  rcws  are  distinct;  duplicate  rows  are  not  allowed. 

5.  Both  the  rows  and  the  columns  can  be  viewed  in  any  sequence  at 
any  time  without  affecting  either  the  information  content  or  the 
semantics  of  any  function  using  the  table  (Martin,  1977:203). 

Database  Management  System.  The  database  management  system  (DBMS) 

consists  of  programs  that  process  data  within  the  database.  It  allows 
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data  to  be  integrated  and  interrelated,  reduces  data  duplication, 
ensures  data  integrity,  eliminates  program  dependency  on  file  formats, 
and  allows  conplicated  entities  to  be  represented  and  retrieved  (Kroenke 
and  Dolan,  1988:9).  A  relational  DBMS  achieves  these  tasks  by  adhering 
to  the  properties  associated  with  that  type  of  relationship  and  data 
representation.  Database  processing  programs  call  the  DBMS  to  access 
stored  data.  This  contrasts  with  traditional  file  processing  programs, 
v^ich  access  stored  data.  This  feature  allows  the  application 
prograiimer  to  be  much  less  concerned  with  the  physical  storage 
characteristics  of  the  data  (Kroenke  and  Dolan,  1988:9-10).  This 
accords  with  what  Martin  states  as  "the  ultimate  objective  of  data-base 
systems":  to  make  application  development  easier,  cheaper,  faster,  and 
more  flexible  (Martin,  1977:34). 

DBMS  Applications.  ;^li  cat  ions  are  programs  that  provide  users 
with  access  to  the  DBMS.  Due  to  the  user-friendly  products  developed  by 
DBMS  vendors,  simple  applications  may  be  developed  by  users  with  little 
or  no  programming  expertise  (Kroenke  and  Dolan,  1988:342).  More  complex 
applications,  such  as  the  subject  of  this  thesis,  may  exceed  the  level 
of  user  expertise  and  make  user  development  impossible.  They  require 
another  party  to  develop  and  maintain  the  application  for  the  user. 

Characteristics  of  a  Good  Relational  DBMS  Application. 

Applications  should  make  maximum  use  of  the  benefits  associated  with 
relational  data  representation  by  meeting  several  characteristics. 

These  characteristics  can  be  divided  into  essential  and  desirable. 

Usable  applications  must  be  able  to  perform  the  following  essentials: 

1,  print  queries  and  update  objects  or  representations  of  things  from 
the  users'  environment. 


17 


2.  allow  users  to  direct  and  control  processing  of  the  application,  and 

3.  always  maintain  security  and  integrity  of  the  database. 

The  ideal  characteristics  of  a  DBMS  center  on  the  application 
being  the  user-database  interface.  Ihe  application  should  be;  easy  for 
authorised  users  to  make  authorised  requests  with  valid  and  accurate 
data,  provide  informative  and  helpful  error  messages  to  authorised  users 
v^o  make  mistakes  or  unauthorised  queries,  and  prevent  unauthorised 
users  from  accessing  the  database.  Unfortunately,  these  characteristics 
are  not  always  realised  due  to  limitations  in  time  and  budget,  knowledge 
or  abilities  of  developers,  and  other  constraints  (Kroenke  and  Dolan, 
1988:256) . 

Research  Question  Two 

Which  are  the  most  appropriate  igystems  analysis  and  software 

techniques  for  developing  a  database  application? 

Information  Systems  Analysis,  Design,  and  Administration 

Preliminary  Investigation.  Ignoring  proper  development  practices 
and  standards  has  lead  to  a  growing  trend  of  poorly  structured  database 
programs  that  cannot  be  maintained  and  must  be  scrapped  (Li skin, 
1988a:79).  While  microcanputer  databases  are  small  vrfien  compared  with 
mainframe  computer  databases,  the  development  process  and  the  need  for 
administration  are  the  same  (Kroenke  and  Dolan,  1988:341).  An  accepted 
definition  of  systems  analysis  states  that  it  involves  the  "examination, 
identification,  and  evaluation  of  components  and  interrelationships 
involved  in  systems"  (Weinberg,  1980:6;  Colter,  1984:52). 

There  are  many  analysis  tools  and  techniques  available  to  system 
developers  to  assist  the  systems  ar<alysis  process  for  computer 
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applications.  Selection  of  a  method  is  necessary  to  ensxire  adequate 
documentation  of  answers  to  the  research  questions  and  specifications 
for  sx±»sequent  software  and  database  development. 

Selection  of  an  Analysis  Method.  Though  many  techniques  are 
available,  none  conpletely  support  the  analysis  process.  A  caiparative 
examination  by  Colter  of  available  techniques  reccanmends  the  adoption  of 
a  package  of  system  representations  as  no  single  tool,  technique,  or 
methodology  can  support  the  complete  analysis  of  today's  ccanplex 
systems.  Organisations  should  adopt  a  package  that  contains  a  minimum 
set  of  system  documentation  with  additional  documentation  appended  where 
necessary.  A  common  and  reccmimended  package  consists  of  data  floiv 
diagrams  (DFDs),  functional  descriptions,  a  hierarchy  chart,  and  the 
data  dictionary.  While  this  form  of  representation  fails  to  clarify 
input/output  detail  or  mechanisms,  it  is  otherwise  complete  (Colter, 
1984:64).  This  deficiency  con  be  ccmpensated  for  by  prototypes  to 
document  user  requirements  for  input  screens,  output  displays,  and 
reports.  The  preference  of  the  investigator  and  the  facilities 
available  in  the  DBMS  product  must  be  taken  into  account  when 
detemining  the  particular  development  method  to  be  employed  (Kroenke 
and  Dolan,  1988:80).  The  investigator  recognised  that  those  tools 
identified  by  Colter  are  part  of  a  standard  package  used  by  the 
Australian  Department  of  Defence  for  at  least  the  past  12  years. 
Communicating  system  requirements  in  a  standard  ccmipact  method  should 
therefore  be  relatively  easy  to  acccxiplish. 

Structured  Analysis  Tools.  The  tools  identified  by 
Colter  have  been  developed  under  the  discipline  of  structured  analysis 
which  lends  itself  to  implementation  through  structured  programming 
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techniques.  Both  techniques  use  a  top-dcwn  approach  to  break  larger 
processes  into  smaller  modules.  Structured  analysis  reduces  the  size  of 
specification  documentation  and  increases  the  level  of  conmunication 
between  analyst  and  user  through  graphics  rather  than  lengthy  narratives 
(DeMarco,  1978:10). 

Data  F1c<>7  Diagrams.  DEDs  portray  a  system  frcm  the  point  of  view 
of  the  data  and  do  not  show  the  control  path  required  for  processing. 
DFDs  consist  of  layered  representations  of  individual  functions  and  the 
flew  of  data  between  those  functions  (Colter,  1984:62).  As  depicted  in 
Figure  l,  four  notational  symbols  are  used  in  DFDs: 

a.  the  data  flow  (or  vector),  which  portrays  a  data  path; 

b.  the  process  (or  bubble),  which  portrays  a  transformation  of  data; 

c.  the  straight  line  that  portrays  a  file  or  a  database; 

d.  the  source  or  sink,  represented  by  a  box,  which  portrays  a  net 
originator  or  receiver  of  data  normally  outside  the  scope  of  the  study 
(DeMarco,  1978:40). 

Functional  Descriptions.  Functional  descriptions  clarify  the 
transformations  performed  on  data  in  the  bubble  processes  of  a  DFD. 

Used  at  the  lowest  level,  functional  descriptions  take  the  form  of 
either  structured  English  or  pseudocode  to  specify  the  logic  involved  in 
the  process  (DeMarco,  1978:304-307). 

Structure  Charts.  As  DFDs  do  not  document  the  control  between 
processes,  another  mechanism,  the  hierarchy  or  structure  chart  is 
required.  These  charts  represent  all  the  modules  in  the  application  and 
illustrate  the  hierarchy  of  control  that  exists  between  each  module 
(Fitzgerald,  1980;  Colter,  1984:63). 
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DATA  FLOW  OR  VECTOR 


Figure  1.  Notational  Symbols  used  in  Data  Flow  Diagrams 


Data  Dictionary.  The  data  dictionary  is  a  tool  that  defines 
the  data  structure  of  the  system  and  aids  the  analyst  in  simplifying  the 
structures  necessary  to  meet  the  data  requirements  of  the  system 
(Colter,  1984:  62-63). 

It  can  be  subdivided  into  descriptions  of  the  data  elanents  and 
descriptions  of  the  relationship  between  the  data  elements  that  form  the 
basis  of  a  database  organisation  or  schema.  Common  use  of  the  term  data 
dictionary  applies  only  to  the  definitions  of  data  elements.  The 
description  of  the  data  elements  should  include  three  definition  aspects 
for  each  element  of  the  system:  the  domain  of  the  property,  which  states 
all  the  possible  values  for  the  data  element;  a  physical  description  of 
the  data  element,  which  states  the  type  of  characters  allowed  in  the 
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data,  length,  and  any  other  restrictions;  and  a  semantic  description 
v^iich  states  the  function  or  purpose  of  the  data  element  and  will 
distinguish  this  property  frcxn  others  that  may  have  the  same  physical 
description  (Kroenke  and  Dolan, 1988:  90-109). 

The  relationships  between  the  data  elements  are  best  illustrated 
through  using  boxes  to  represent  entities  or  records  and  lines  as 
relationships  between  entities.  These  diagrams  are  ccaimonly  referred  to 
as  entity- relationship  (ER)  diagrams  or  logical  data  structures.  Figure 
2  illustrates  the  notation  used  in  ER  diagrams.  The  specific 
relationships  between  data  elements  within  and  between  entities  are 
represented  using  entity-attribute  (EA)  lists  limited  to  terms  defined 
under  the  data  dictionary.  Together  ER  diagrams  and  EA  lists  are 
referred  to  as  a  data  model . 
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Figure  2.  Notation  used  in  Entity  Relationship  Diagrams 


Normalization.  Normalization  is  the  process  of  "elimination  and 
consolidation  of  redundant  data  elements  in  a  database  (Nantucket 
Corporation,  1987:  Glossary  v)".  An  unnormalised  database  can  contain 
unnecessary  occurrences  of  information  located  in  different  records. 
This  can  lead  to  difficulties  in  ensuring  the  accuracy  of  all 
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occurrences  of  that  data  during  additions,  modifications  and  deletions. 
These  difficulties  are  collectively  referred  to  as  modification 
ananaiies  (Kroenke  and  Dolan,  1988:133-134).  Normalization  aims  to 
identify  and  eliminate  modification  ananaiies  within  the  data  model  to 
achieve  all  the  benefits  of  relational  database  structures  (Kroenke  and 
Dolan,  1988:133-134). 

six  different  levels  of  normalization  theory  were  identified 
between  1970  and  1981.  Not  until  R.  Fagan  defined  the  domain/key  normal 
form  (DK/NF)  could  data  be  shown  to  be  free  from  all  modification 
ananaiies  regardless  of  their  type  following  the  normalization  process 
(Kroenke  and  Dolan,  1988:137-156).  "Fran  a  practitioner's  viev;point  the 
most  important  normal  form  is  DK/NF"  (Kroenke  and  Dolan,  1988:137-8). 
DK/NF  is  the  primary  design  goal  v^en  constructing  record  definitions 
(Kroenke  and  Dolan,  1988:149). 

Fortunately,  relational  design  can  also  be  approached 
synthetically  using  the  relationships  among  data  elements  and  can  be 
used  to  construct  a  logical  database  design  that  is  in  DK/NF  (Kroenke 
and  Dolan,  1988:163).  All  relationships  can  be  expressed  as  binary 
relationships  between  entities  in  either  one-to-one  (1:1),  one-to-many 
(1:M)  or  many-to-many  (M:M)  format.  The  latter  of  these  is  represented 
as  two  1:M  relationships  (Martin,  1977:66-80).  Additionally,  all 
relationships  are  either  optional  or  mandatory  in  nature  (Kroenke  and 
Dolan,  1988:168-183).  Only  necessary  occurrences  of  data  are  retained 
in  the  databases  to  represent  these  relationships. 
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Database  Administration 

Database  administration  for  microcomputers  is  easier  than  for 
larger  systems  because  databases  tend  to  be  smaller  providing  less  to 
administer.  Unfortunately,  this  task  is  often  undertaken  by  those 
without  the  skills  normally  found  within  an  organisation's  MIS 
department,  'ttie  user  must  undertake  many  functions  such  as  file 
backups,  as  there  is  no  professional  database  administrator  (DBA) 
available  in  the  typical  microcomputer  database  environment  (Kroenke  and 
Dolan,  1988:344-345). 

Some  of  the  DBA's  responsibilities  include:  management  of  the 
database  activity,  managing  the  database  structure,  management  of  the 
DB'IS  softv/are,  control  of  concurrent  processing,  database  backup  and 
recovery,  database  security,  and  development  of  new  database 
applications  including  all  the  associated  documentation  (Kroenke  and 
Dolan,  1988:223).  Many  of  these  tasks  are  better  suited  to  experienced 
MIS  professionals  and  DSC-AF  will  act  as  the  DBA  following  development 
of  the  prototype  (Haren,  1989). 

Prototype  Development 

Prototypes  reduce  the  risks  and  costs  associated  with  system 
failures.  Itiey  are  normally  developed  for  the  more  critical  and 
difficult  functions  of  a  larger  system  (Senn,  1984:20-21).  A  strategy 
proposed  by  Barcanb  for  the  introduction  of  office  automation  relies  on 
"prototype,  pilot,  production"  (Barcanb,  1989).  This  thesis  will 
develop  prototype  modules  of  a  larger  MT  MIS  for  user  evaluation  as  a 
pilot  study.  This  v/ill  reduce  the  risk  associated  with  development  of  a 
large  information  system. 
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structured  Analysis  Life  Cycle 

There  are  many  articles  and  books  that  discuss  the  design  and 
evaluation  of  information  systems.  Each  divide  the  process  into  several 
steps  that  must  be  completed  in  order  to  analyse,  design,  develop,  and 
maintain  applications  successfully.  These  stages  of  a  systems 
development  cycle  are  not  discrete.  Tasks  contained  within  each  stage 
may  be  repeated  many  times  throughout  the  life  cycle  of  an  application 
and  one  stage  does  not  need  to  be  totally  complete  before  another  is 
commenced . 

The  development  of  an  MIS  involves  three  broad  stages:  definition  of 
the  system,  physical  design  of  the  system,  and  implementation  of  the 
system  (Davis  and  Olsen,  1985).  Successful  implementation  of  a  MIS  is 
directly  related  to  the  quality  of  the  development  process  (Alter  and 
Ginzberg,  1978:23-31).  While  the  particular  method  used  to  develop  a 
computer  application  depends  on  the  size  and  complexity  of  the  project, 
development  of  a  database  system  requires  similar  development  steps  as 
any  business  computer  system  (Kroenke  and  Dolan,  1988:75).  Many  small 
and  large  organisations  are  adopting  the  Structured  Analysis  Life  Cycle 
as  a  standard  tool  for  developing  computer  systems  (Yourden,  1989:78). 
This  life  cycle  encompasses  all  development  steps  encountered  in  the 
literature.  Nine  phases  proposed  by  Yourden  for  system  development 
under  the  Structured  Analysis  Life  Cycle  are:  survey,  analysis,  design, 
implementation,  acceptance  test  generation,  quality  assurance,  procedure 
description,  database  conversion,  and  installation  (Yourden,  1989:88- 
94).  Figure  3  illustrates  these  phases  and  the  relationship  between 
them. 
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Phose  1:  Survey.  The  survey  phase  defines  what  the  project  is 
attempting  to  achieve.  This  stage  identifies  personnel  involved  in  the 
project,  user  perceptions  of  data,  and  deficiencies  in  the  users' 
current  environment.  An  initial  scope  is  developed  to  limit  the  size 
of  the  project  to  certain  functions  and  certain  users.  Two  major  tools 
are  used  in  this  process:  the  Initial  Context  DFD  and  the  Event  List. 

Ilie  Initial  Context  DFD  represents  a  high  level  view  of  the 
fol lowing: 

a.  The  people,  organisations,  or  systems  with  v^ich  the  systan  will 
communicate.  These  are  called  terminators. 

b.  The  data  the  system  will  receive  from  the  outside  world  that  must 
be  processed  in  seme  way. 

c.  The  data  produced  by  the  system  and  sent  to  the  outside  world. 

d.  The  data  stores  that  are  shared  between  the  system  and  the 
terminators. 

e.  Ttie  boundary  between  the  system  and  the  outside  world. 

The  event  list  is  a  narrative  list  of  all  the  events  that  occur 
outside  the  system  to  which  the  system  must  respond.  The  events  consist 
of  tvio  types.  Flow-oriented  events,  labeled  F,  occur  when  a  piece  of 
data  has  arrived  from,  outside  the  system.  These  events  will  relate  to  a 
dataflow  on  the  context  DFD,  but  not  all  dataflows  are  related  to  flow- 
oriented  events.  Temporal  events  are  triggered  by  the  arrival  of  a 
point  in  time  and  are  not  triggered  by  a  flow-oriented  event. 

Goals  and  objectives  of  the  new  system  are  also  agreed  upon  with 
users.  The  feasibility  of  using  automation  to  solve  the  problem  must  be 
considered,  taking  into  account  cost,  t^'^hnical ,  and  scheduU  issues 
(Kroenke  and  Dolan,  1988:78).  Most  importantly,  a  project  charter  or 


27 


target  document  must  be  prepared  incorporating  all  the  above  details. 
This  document  describes  the  details  of  the  project  life  cycle  that  will 
follow  and  will  be  used  to  guide  the  remainder  of  the  project. 

Phase  2;  Systems  Analysis.  The  primary  purpose  of  the  systems 
analysis  phase  is  to  transfer  user  requirements  and  the  target  document 
into  a  structvired  specification.  This  transformation  involves  modeling 
the  users'  environment  using  structured  analysis  tools  such  as  DFDs  and 
data  models.  This  structured  specification  defines  what  the  system  must 
do  to  meet  the  user  requirements  of  the  system. 

Phase  3:  Design.  Portions  of  the  structured  specif ication  are 
allocated  to  appropriate  processors,  either  man  or  machine.  The  design 
phase  incorporates  the  development  of  a  blueprint  for  the  database  and 
the  applications.  Data  models  are  transformed  into  database  designs. 
Application  blueprints  are  designed  and  represented  in  structure  charts 
and  pseudocode.  Reports  and  menus  should  be  formatted.  All  design 
documents  should  be  subjected  to  a  thorough  review  by  users  before  the 
next  stage.  This  represents  the  last  opportunity  to  find  errors  before 
building  the  applications.  The  costs  of  mistakes  at  this  point  are  lew 
compared  to  mistakes  made  during  the  implementation  phase. 

Phase  4;  Implementation.  During  the  implementation  phase,  the 
actual  database  is  constructed  and  the  application  programs  are  coded 
using  structured  programming  techniques  and  a  top-down  approach. 

Phase  5;  Acceptance  Test  Generation.  An  acceptance  test  should  be 
conducted  with  both  new  and  old  systems  mnning  in  parallel  to  validate 
that  the  system  does  what  it  is  designed  to  do.  The  test  criteria  must 
be  derived  from  the  target  document  in  the  requirement  phase  and  agreed 
with  the  users.  Test  cases  are  often  derived  in  conjunction  with  users. 


This  test  closes  the  loop  between  requirement  and  implanentation  phases. 


Phase  6;  Quality  Assurance.  'Hie  quality  assurance  phase  is  the 
acceptance  test  performed  by  users  or  some  independent  body.  Minor 
corrections  are  acceptable  at  this  stage  but  the  acceptance  test  does 
not  form  part  of  a  debugging  process,  'rtie  results  of  the  acceptance 
test  are  binary:  either  the  project  was  a  success  and  met  its  targets  or 
it  did  not.  (De  Marco,  1978:325-326). 

Phase  7:  Procedure  Description.  The  Structured  Analysis  Life 
Cycle  considers  the  entire  system  environment  and  not  just  the  autonated 
portion.  User  manuals  are  produced  to  describe  how  the  users  will 
interact  with  the  system. 

Phase  8:  Database  Conversion.  In  this  phase,  all  current 
databases  relevant  to  the  system  are  converted  to  the  new  database 
format,  or  the  information  is  transferred. 

Phase  9:  Installation.  As  the  final  activity,  the  accepted 
applications,  converted  database,  and  user  manuals  are  installed  into 
the  user  organisation.  A  period  of  parallel  running  of  new  and  old 
systems  may  follow  to  allow  system  introduction  to  users  (De  Marco, 
1978:325-326:  Yourdon,  1989:88-94). 

Software  Selection 

There  are  a  large  number  of  DBMS  software  packages  available  for 
use  in  developing  database  applications  on  microccwiputers.  The  most 
popular  languages  for  accessing  the  database  are  part  of  a  DBMS  package 
and  often  use  an  interpreter  to  convert  source  code  into  machine  code. 
These  are  called  DBMS-specific  programming  languages  as  they  pertain  to 
only  one  DBMS  and  include  the  popular  dBASEf*^  series  by  Ashton-Tate 
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(Kroenke  and  Dolan,  1988:73).  "dBASE?**  is  considered  the  standard 
against  which  all  other  dBASE^*  software  should  be  judged"  (Liskin, 

1983 :1C3).  .A.  number  of  dBASE?*  clones  developed  over  recent  years  have 

included  the  use  of  ccnipilers.  A  conparison  of  their  features  shows 
they  have  begun  to  outstrip  even  the  latest  dBASE™  version  —  dBASE 
--  with  regard  to  building  application  programs  (Schartz,  1989:89-106). 
dBASE  I\^  has  been  described  as  adopting  the  middle  ground  between 
supporting  novice  and  professional  programmers  (Liskin,  1988:104-112). 

Database  Compilers.  A  database  connpiler  is  a  programming  routine 
that  enables  a  computer  to  convert  a  program  expressed  in  pseudocode 
language  into  machine  language  or  another  pseudocode  language  for  later 
translation  (Stratley,  1988:49). 

The  use  of  compilers  provides  certain  advantages  over  interpreter- 
based  languages  especially  in  the  areas  of  speed,  security  of  source 
code,  and  cost.  A  compiled  application  will  run  significantly  faster 
than  an  interpreted  application  because  the  code  is  already  in  machine 
understandable  format  and  does  not  need  further  conversion.  This 
converted  code  cannot  easily  be  tampered  with  by  curious  users  and 
provides  a  great  deal  of  security  for  program  source  code  as  well  as 
protecting  the  manner  in  vAiich  the  database  is  manipulated.  This  means 
that  the  responsibility  for  application  development  and  maintenance 
remains  with  the  organisation  having  access  to  the  source  code.  Tliis 
ensures  consistency  and  control  of  application  programs  especially  v^en 
used  by  several  users.  Cost  savings  accrue  from  the  need  to  purchase 
only  one  copy  of  the  licenced  DBMS  software  for  use  at  the  development 
and  maintenance  site.  With  interpreter-based  applications  a  copy  of  the 
interpreter  software  would  be  required  at  each  user  site  to  enable  use 
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of  the  applications.  At  a  cost  of  between  U3$200  and  US$800  for  each 
licenced  copy  of  the  DBMS  software,  this  beccroes  an  inportant  aspect  in 
a  multiple  user  MIS  environment. 

Cl ipper^^ .  Nantucket  Corporatiwi's  Summer  '87  edition  Clipper^*^ 
software  is  described  as  the  "best  dBASE™  compiler  on  the  market"  as  it 
allows  the  building  of  professional  applications  with  useful  user- 
friendly  context-sensitive  elements  (Nantucket  Corporation,  1987; 
Schartz,  1989:104).  Additionally,  as  a  development  tool,  Clipper*^  is 
the  high-speed  equivalent  of  dBASE  for  use  by  professional 

programmers  (Monk  and  Landis,  1988:56). 

Despite  a  relatively  low  profile  in  the  computer  industry  compared 
with  Ashton-Tate's  products,  Clipper^**  holds  5%  of  the  microcanputer 
database  market  (Mace,  1989a:20).  It  has  been  successfully  used  to 
develop  some  commercial  database  applications  in  such  large  and 
noteworthy  organisations  as  Sotheby's  Holdings  Incorporated  (Stoll, 
1989:48-49) , 

Application  Development  Period.  Timesaving  application 
development  tools  are  available  for  use  with  Clipper^*'.  Concentric  Data 
System's  Relational  Report  Writer^*  version  3  and  Relational  Report 
Writer  Code  Generator^**  version  l  will  enable  professional  reports  in 
Clipper^**  application  programs  (Concentric  Data  Systems,  1988; 

Concentric  Data  Systems,  1989).  UI  Developer's  Release  version  2™  will 
assist  in  production  of  Clipper^**  code  for  many  common  database  routines 
as  well  as  user  display  and  menu  interfaces  (Wallsoft  Systems  Inc., 1989) 

Compatibility.  iTie  Clipper^**  compiler  will  also  support  slightly 
modified  dBASE  II^^  and  dBASE  III^**  code  (Schartz,  1989:99).  This 
compatibility  will  allow  utilisation  of  previously  developed  dBASEf* 
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source  code  in  this  application  and  future  programs  in  the  MT  MIS. 

Future  Software  Developments.  Additional  developments  forecast 
for  the  Clippe/**  version  5.0  due  for  release  in  1990,  will  allow  true 
object-oriented-programming  (OOP)  and  interfaces  to  other  than  dBASEf** 
type  databases  such  as  IBM's  Structured  Query  Language™  (SQL) 

(Johnston,  1989:5;  Mace,  I989b:20).  OOP  is  an  important  breakthrough  in 
programming  development  and  can  be  used  in  the  design  of  relational 
databases  (Blaha  et  al ,  1988:414-427).  SQL™  has  developed  as  a 
standard  in  the  database  processing  industry  and  is  implemented  in 
various  database  products  such  as  ORACLE?**  and  DB2™  (Oracle  Corporation, 
1989;  Kroenke  and  Dolan,  1988:321).  Both  of  these  products  are 
currently  used  in  the  Australian  Department  of  Defence  and,  as  IBM 
products,  should  ranain  in  use  following  the  implementation  of  DEBINE. 
Due  to  the  current  performance  characteristics  and  forecast  features, 
the  investigator  selected  Clipper^**  as  the  DBMS  for  application 
development  in  this  thesis.  The  software  should  insure  its  availability 
and  ccxnpatibi 1 ity  for  the  life  of  the  application. 

Summary 

This  chapter  documented  the  literature  review  undertaken  to 
provided  answers  to  the  first  two  research  questions  from  Chapter  I. 

Research  Question  One. 

Is  a  database  suitable  for  improving  the  efficiency  of  RAAF 

MT  asset  management? 

An  overview  of  previous  related  studies  undertaken  in  the  ADF  and  the 
USAF  illustrated  the  similarities  in  problem  issues  and  identified 
possible  solutions.  The  Defence  Commercial  Vehicle  Review  saw  the  need 
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for  development  of  an  MT  fleet  MIS  to  improve  MT  asset  management 
effectiveness  and  efficiency.  A  microcomputer  information  system  using 
database  programming  anerged  as  a  common  solution  fron  other  ADF  and 
USAF  MT  asset  management  studies. 

Of  possible  database  organisations,  relational  databases  offer  the 
greatest  potential  for  use  with  microcomputers.  Many  DBMSs  are 
available  and  make  application  development  easier,  cheaper,  faster,  and 
more  flexible  than  traditional  file  processing  systems.  Maintenance  of 
applications  is  the  responsibility  of  the  DBA.  DSC-AF  will  fulfill  that 
role  for  any  applications  developed  in  this  thesis  (Haren,  1989). 

Research  Question  Tyjo. 

Which  are  the  most  appropriate  systems  analysis  and  softv;are 

techniques  for  developing  a  database  application? 

Important  issues  supporting  the  selection  of  a  structured  systems 
analysis  methodology  and  a  documentation  package  were  detailed.  Though 
many  systems  analysis  techniques  are  available,  none  completely  support 
the  analysis  process.  A  package  approach  using  a  number  of  techniques 
appeared  as  the  most  appropriate  tool  for  documenting  development  of  a 
database  application. 

The  proper  development  of  underlying  database  structures  were 
found  to  be  important  for  successful  applications.  A  formal  application 
development  methodology  for  use  in  conjunction  with  structured  systems 
analysis  vras  introduced.  The  Structured  Analysis  Life  Cycle  emphasizes 
development  of  the  database  structure  prior  to  development  of  the 
applications  and  provides  structure  for  use  of  the  package  of 
development  tools.  The  methodology  is  accepted  as  a  valid  and  reliable 
industry  standard  for  use  in  developing  computer  systems. 
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Software  techniques  to  implement  relational  databases  on 
microccxnputers  were  examined.  Database  canpilers  offer  additional 
advantages  over  other  DHIS  software  packages  for  application 
development.  Clipper™  is  assessed  as  the  best  database  compiler 
conmercial ly  available  and  can  be  used  with  timesaving  development 
tools.  Clipper™  was  chosen  as  the  software  for  implementation  of  the 
application. 
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III.  Methodology 


Chapter  Overview 

Hie  accat?3lishinent  of  the  research  objectives  followed  a  series  of 
steps  based  on  the  Structured  Project  Life  Cycle.  Sane  of  the  steps 
were  more  applicable  than  others  to  this  project,  so  there  was  more 
emphasis  in  those  areas.  These  steps  paralleled  research  questions 
three  through  seven  detailed  in  Chapter  l.  Table  l  is  a  timetable  of 
the  research  methodology  process  and  shows  the  relationship  between  the 
methodology  and  the  research  questions. 

Phase  1:  Survey 

This  phase  defined  the  problem  to  be  solved  by  the  application, 
and  identified  users  of  the  application,  as  the  three  members  in  the 
M0VT2  area  of  IM)VT-AF.  Approval  was  sought  and  granted  by  the  Director 
of  Movements  and  Transport  -  Air  Force  for  the  project  (Miller,  1989). 

He  appointed  the  senior  officer  in  the  MT  management  area  (M0VT2)  as  the 
liaison  officer  and  approved  the  use  of  interviews  with  that  person 
(Miller,  1989). 

What  is  the  Project  Trying  to  Achieve?  A  review  of  current 
regulations  and  management  requirements  assisted  in  determining  sane 
initial  data  processing  needs  and  information  requirements  for  EMOVT-AF 
establishment  management.  Elements  from  the  literature  review  provided 
a  conmon  frame  of  reference  for  definitions  and  concepts  used 
in  this  and  subsequent  phases.  The  investigator  requested  sample 
reports  from  DMOVT-AF  to  assist  in  initial  definition  of  the  problem 
scope.  Semi -structured  questions,  an  initial  context  DFD,  and  an  event 
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Table  1 


Research  Timetable 


Research 

Phase 

Inclusive  Dates 

Question 

3. 

1. 

Survey 

Nov  89 

-  Jan 

90 

3. 

2. 

Systans  Analysis 

Dec  89 

-  Mar 

90 

4. 

3. 

Design 

Mar  90 

-  Apr 

90 

5. 

4. 

Implementation  Phase 

May  90 

-  Jun 

90 

6. 

5. 

Acceptance  Testing 

Generation 

May  90 

-  Jun 

90 

7. 

6. 

Quality  Assurance 

Jun  90 

-  Jul 

90 

7, 

Procedure  Description 

Jul  90 

-  Aug 

90 

8. 

Database  Conversion 

Feb  90 

-  Mar 

90 

9, 

Installation 

Jun  90 

-  Aug 

90 

list  were  developed  as  tools  for  describing  the  system  scope.  The 
project  can  be  summarised  as  trying  to: 

a.  present  a  more  flexible  and  useable  MT  establishment  database  by 
replacing  the  current  rudimentary  data  processing  system,  and 

b.  autcanate  data  record  keeping  functions  for  ra40VT-AF  with  respect  to 
establishment  tables  and  associated  information. 

What  Deficiencies  Exist  in  the  Current  System?  The  major 
deficiency  of  the  current  system  is  the  manner  of  accessing  information 
about  the  RAAF  MT  establishment.  The  system  is  inflexible,  manpower 
intensive,  and  overly  time  consuming  (Miller,  1989).  Due  to  the  volume 
of  the  data  involved,  the  system  is  also  prone  to  error.  It  requires 
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the  use  of  personnel  to  compile  and  maintain  the  data  on  unrelated 
manual  files  and  in  word-processed  format  on  a  microccmputer.  Retrieval 
of  historical  data  poses  problems.  Information  storage  is  unstructured 
and  information  cannot  be  readily  extracted  or  updated.  Lack  of  access 
to  this  information  deprives  all  MT  management  levels  of  information 
necessary  for  vehicle  use  control.  Vehicles  are  often  employed  for 
purposes  for  wfiich  they  were  not  intended.  Staff  turnover  at  all 
management  levels,  coupled  with  the  poor  data  accessibility,  exacerbates 
this  problem.  With  the  exception  of  the  unit  establishment  tables,  the 
current  system  is  unable  to  produce  useful  management  reports. 

What  is  the  Initial  Scope  of  the  Project?  The  initial  scope  of 
the  project  was  documo.ited  in  a  Initial  Context  DFD  and  Event  List.  The 
Initial  Context  DFD  represented  the  information  requirements  of  the 
proposed  system  as  they  relate  to  the  organisational  elements  defined  in 
Chapter  II  The  Event  List  was  a  narrative  list  of  all  the  events  that 
occur  outside  the  system  to  v^ich  the  system  must  respond.  WVT2  was 
asked  to  examine  the  Initial  Context  DFD  and  Event  List  for  accuracy. 
During  the  interview,  attempts  vrere  made  to  correct  any  deficiencies  in 
the  diagram  and  list.  A  revised  Target  Document  was  submitted  to  the 
interviewee  and  was  accepted.  ;^pendix  A  is  the  agreed  Target  Document. 

Due  to  the  different  sizes  of  establishment  tables  and  their 
varying  levels  of  complexity,  time  taken  to  perform  tasks  before 
implementation  was  difficult  to  estimate.  However,  M0VT2  and  M0VT2A 
recorded  some  estimates  for  later  comparisons  in  the  acceptance  testing 
phase . 

Feasibility  to  Automate?  DMOVT-AF  currently  operates  a  NCR  PC  810 
Model  MCH4175  computer  with  an  MSDOS  operating  system,  640  kilobytes  of 
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random  access  memory,  EGA  monitor,  360  kilobyte  5.25  inch  disk  drive  and 
30  megabyte  hard  disk  (Haren,  1990),  The  investigator  estimated  data 
storage  requirements  using  rough  drafts  of  record  size  and  number  of 
occurrences  of  each  record  plus  allowance  for  indexes  and  programs. 
Storage  requirements  of  the  current  system  appeared  adequate  for 
development  of  an  application.  Autcanating  IMJVT-AF  establishment 
managanent  was  evaluated  as  feasible  on  this  microcomputer  using 
C 1  i  pper^*  sof  tware . 

Phase  2:  systems  Analysis 

This  phase  applied  the  selected  systems  analysis  tools  to  express 
user  requirements  as  models  of  processes,  data  relationships,  and  data 
definitions.  A  data  dictionary  was  developed.  Further  interviews  were 
required  to  verify  requirements  and  data  definitions. 

Phase  3;  Design 

structured  systems  analysis  techniques,  in  conjunction  with  user 
requirements,  determined  the  processes  for  automation,  and  those  which 
should  not  cross  the  man-machine  boundary.  Those  areas  not  considered 
feasible  for  implementation  on  an  automated  system  were  highlighted  and 
accepted  by  the  user.  Time  constraints  forced  a  further  reduction  in 
the  scope  of  the  project.  Establishment  Variation  Request  (EVR) 
processing,  originally  earmarked  for  automation,  was  eliminated  frcm  the 
scope  of  the  project.  This  area  was  of  a  lesser  priority  than  others 
identified  by  the  user  and  would  have  required  interfaces  with  a  system 
at  the  RMS  level  to  avoid  duplicate  data  entry.  Data  models  for  these 
areas  were  retained  to  illustrate  the  relationship  of  data  in  this 
system  to  the  remainder  of  the  OT  management  environment.  The  user 
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agreed  that  these  areas  would  need  to  be  developed  at  sane  later  stage, 
niis  is  discussed  in  greater  detail  in  the  next  chapter.  The  target 
document  was  amended  accordingly. 

Alternative  conputer  architecture  was  not  considered  due  to  the 
implementation  of  the  DESINE  project.  All  hardware  and  other 
infrastructure  was  already  in  place  for  implementation  of  applications 
within  the  scope  of  this  thesis.  No  additional  costs  were  encountered 
above  those  already  considered. 

Phase  3  developed  blueprints  of  the  database  and  application 
programs.  As  all  functions  of  the  new  system  revolved  around  management 
of  an  establishment  database,  emphasis  was  place  on  correct 
identification  of  data  requirements  and  development  of  DFDs  was  limited 
to  generic  add,  edit,  and  delete  functions.  Psuedocode  was  also 
developed  for  these  functions. 

A  data  dictionary  was  developed  on  dBASE  III  Plus  and  produced 
with  Relational  Report  Writer^^.  This  documented  the  process  of 
extracting  data  formats,  size,  type,  authority  and  source  frcan  current 
reports  and  Defence  Instructions.  The  data  dictionary  appears  at 
Appendix  B.  Data  in  the  dictionary  was  normalised  to  third  normal  form 
to  reduce  redundancy  and  enhance  the  use  of  relational  database 
structures.  EA  lists  produced  fron  the  database  using  Relational  Report 
Writer^**  appear  at  i^jpendix  C.  These  were  matched  to  diagrams 
illustrating  the  relationships  betvveen  data.  The  ER  diagram  appears  at 
Figure  9.  Data  models,  including  the  EA  lists  and  ER  diagrams  were 
despatched  with  the  data  dictionary  to  EM)VT-AF.  Follow-up  semi- 
structured  telephone  interviews  confirmed  the  accuracy  of  the  plans 
prior  to  the  next  stage. 
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Phase  4;  Implementation 

Phase  4  transformed  those  areas  identified  as  better  suited  to 
automation  into  Clipper^'*  programs  using  structured  programming's 
top-down  approach.  Figures  4  through  8  illustrate  the  structure  chart 
developed  to  provide  the  investigator  with  a  skeleton  framework  of 
modules  that  required  development.  UI2™  provided  d  relatively  quick 
means  of  developing  user  friendly  pull-down  and  light -bar  menus  in  the 
Clipper^**  language  for  the  main  menu,  add,  edit,  and  lookup  routines. 
Relational  Report  Writer^**  and  its  code  generator  were  used  to  develop 
Clipper^*'  reports  from  actual  and  test  databases.  and  Relational 

Report  Writer^**  code  generators  use  structured  programing  techniques 
that  aided  modular  development.  User  defined  functions  and  other  common 
routines  were  extracted  from  these  programs  to  reduce  the  overall  size 
of  the  application.  Code  from  these  programs  was  extensively  modified 
to  integrate  all  elements  of  the  application  and  provide  checks  of  data 
input  to  ensure  validity.  Delete  programs  were  developed  to  make  use  of 
common  lookup  procedures.  All  programs  were  developed  with  common 
formats  and  controls  to  reduce  the  need  for  user  adaptation.  All 
programs  were  compiled  with  Clipper^*^  and  linked  with  Pi  ink  86  Plus'*'  to 
form  a  stand-alone  executable  program  (Phoenix  Technologies  Ltd,  1986). 

The  applications  modules  were  matched  to  the  event  list  developed 
in  the  Survey  Phase.  TTie  database  constructed  frc«n  the  logical  data 
representations  developed  in  Phase  3  was  loaded  with  sample  data  as  part 
of  the  testing  of  add  program  modules.  Programs  were  extensively  tested 
for  validity  and  reliability  by  the  investigator.  Observations  of  AFIT 
volunteers'  reactions  v/ere  used  to  assess  user  interfaces  v;ith  the 
application  (Fogg,  1990;  Noble,  1990). 
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Figure  4.  Structure  Chart  --  Main  Menu  Modules 


Three  versions  of  the  application  were  sent  to  EMOVT-AF  for  field 
testing  and  evaluation.  The  first  version  contained  user  interface 
modules  to  add,  edit,  and  delete  data  fron  the  databases.  The  second 
version  added  report  functions,  but  had  to  be  sent  as  two  separate 
applications  due  to  canpjter  memory  constraints.  These  constraints  were 
overcome  and  the  final  version  combined  all  programs  into  one 
application  and  included  additional  help  features. 

Phase  5:  Acceptance  Test  Generation 

Cases,  based  on  user  requirements  stated  in  the  target  document, 
were  developed  to  test  the  functionality  of  the  application  before  it 
vras  forwarded  to  Australia.  These  mainly  centered  around  providing  the 
abilities  to  add,  edit,  delete,  and  report  data  found  in  current  reports 
used  by  C»'K)VT-AF. 

Phase  6:  Quality  Assurance 

Phase  6  evaluated  the  nev/  application.  Selected  AFIT  personnel 
with  computer  expertise  performed  a  technical  review  of  the  application 
(Beard, 1990;  Fogg,  1990;  Noble,  1990).  Once  the  investigator  was 
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LOOKUP  PROGRAMS  ARE  CALLED  BT  ALL  RESPECTIVE 

add,  edit,  and  delete  programs 


L_MOBI L I  TV 


LOOKUP  SURFACE 
MOB  1 L I TY 
CATEGORY 


U_SV_CAT 


LOOKUP  SURFACE 
VEHICLE 
CATEGORY 


L_VEH_ROLE 


LOOKUP  SURFACE 
VEHICLE  ROLE 


l_est_type 

l_deploy 

lookup 

ESTABL 1 SHMENT 
TYPE 

lookup  vehicle 
deployment 

CATEGORY 

1 _ EST.AUTH 

! 

L_CUSTEL 

lookup 

ESTABL 1 SHMENT 
AUTHOR  1  TY  LI  HE 

1 

lookup  CUSTOMER  I 
ELEMENT 

L_E_UNIT 

l_r_a:jndt 

lookup 

ESTABL 1 SHMENT 

UN  1  T 

lookup  SURFACE 
VEHICLE  ROLE 

annotat ion 

L_C_UNI T 


L'XiKUP  CUSTOMER 
UNIT 


L_e_TABLE 


LOOKUP 

ESTABL I SHMENT 
TABLE 


Figure  6.  Structure  Chart  --  Delete  and  Lookup  Modules 
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REPORT 

SUB-hCMU 


Figure  8.  Structure  Chart  --  Report  Modules 


satisfied  that  all  the  requirements  of  the  target  document  were  met,  the 
system  was  implemented  at  DMOVT-AF  for  parallel  acceptance  testing. 
D^K)VT-AF  staff  assessed  the  usefulness  and  acceptance  of  the  system 
using  De  Marco's  acceptance  testing  criteria  (De  Marco,  1978:325).  They 
quantified  any  improvements  in  efficiency  as  a  result  of  implementing 
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the  application.  These  are  discussed  in  the  Chapter  4.  Additional 
telephone  interviews  were  conducted  with  M0VT2  (Haren,  1990). 

Phase  7;  Procedure  Description 

A  user  manual,  including  a  tutorial,  was  written  explaining  basic 
concepts  and  start  procedures  for  the  application.  Screen  displays  were 
captured  using  Pizzaz  Plus™  software  and  imported  into  WordPerfect™ 
word  processing  software  to  illustrate  the  manual  with  examples  from  the 
application  (;^li  cat  ion  Techniques,  1988;  WordPerfect  Corp,  1989). 
Context-sensitive  error  messages  and  on-screen  instructions  developed  as 
part  of  the  application  negated  the  need  for  a  large  manual.  Appendix  D 
is  the  User  Manual. 

Phase  8;  Database  Conversion 

The  word-processed  information  located  at  DMOVT-AF  could  not  be 
converted  to  the  new  database  format.  DMOVT-AF  supplied  current 
establishment  tables  for  four  RMSs  >rtaren,  1990).  Data  from  two  tables 
was  loaded  as  sample  data  into  the  new  format  with  the  remainder  to  be 
loaded  after  installation.  Vehicle  information  held  at  SG3  also  could 
not  be  converted  to  the  new  database  due  to  differences  in  data  formats. 
Specifications  and  reports  v/ere  provided  by  SG3  (Taylor,  1990). 

Important  data  from  these  was  loaded  by  the  investigator  to  facilitate 
testing. 

Phase  9:  Installation 

The  user  manual,  accepted  application  programs,  and  partially 
converted  database  v«re  implemented  at  r»-K)VT-AF  on  19  July  90. 
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SiJinmary 

This  chapter  detailed  the  series  of  steps  based  on  the  Structured 
Project  Life  Cycle.  This  methodology  was  used  to  accorplish  the 
research  objectives  and  resulted  in  the  development  of  a  prototype 
application  program.  Chapter  IV  will  detail  the  findings  of  the 
research  as  they  relate  to  the  research  questions  fran  Chapter  I. 
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IV.  Findings  and  Discussion 


Chapter  Overview 

Chapter  I  of  this  thesis  developed  seven  research  questions  to 
determine  if  a  microcomputer  database  application  could  improve  the 
efficiency  of  BAAF  MT  establishment  management.  The  first  two  questions 
were  answered  by  the  research  undertaken  in  the  literature  review 
documented  in  chapter  II.  This  chapter  details  the  findings  of  the 
thesis  as  they  relate  to  the  other  questions  and  related  issues. 

Research  Questions 

Research  Question  Three. 

What  are  the  data  processing  and  information  requirements 

for  executive  level  RAAF  MT  asset  managanent? 

"While  published  data  are  a  valuable  resource,  seldom  is  more  than  a 
fraction  of  the  existing  knowledge  in  a  field  put  into  writing"  (Emery, 
1985:63) . 

While  the  literature  review  provided  a  valuable  insight  into  the 
policy  and  procedures  surrounding  the  management  of  the  RMF's  MT  fleet, 
not  all  aspects  had  been  documented.  This  was  especially  true  of  those 
procedures  that  were  internal  to  CMOVT-AF. 

In  an  attempt  to  overcome  the  disjointed  MT  information  system 
development  described  in  Chapters  l  and  2,  the  investigator  attempted  to 
account  for  as  many  views  of  MT  data  as  possible.  This  led  to  the 
production  of  a  large  ER  diagram  illustrating  the  relationships  between 
information  in  all  three  major  levels  of  ifT  management.  The  scope  of 
developing  such  an  integrated  MIS  was  not  possible  v/ithin  the  thesis 


48 


time  line,  but  the  incorporation  of  the  data  relationships  in  an 
establishment  management  subsystem  would  enable  later  integration. 
Haventree  Software  Limited's  EasyfliW**  was  used  to  produce  and  maintain 
the  ER  diagrams  and  DFDs  (Haventree,  1989).  ;^)pendix  E  illustrates 
relationships  to  be  considered  in  an  MT  MIS. 

The  relationships  and  information  that  form  this  application  can 
be  seen  as  only  a  small  element  of  v^at  would  comprise  a  larger 
integrated  MIS.  The  establishment  management  information  gathered 
reflects  EMOVT-AF's  concentration  on  higher  level  policy  and 
establishment  issues.  For  that  reason,  individual  vehicle  and  other 
transaction  specific  information  was  considered  outside  the  scope  of 
this  system  and  more  correctly  was  the  danain  of  the  vehicle  manager, 
SG3,  and  PMSs. 

The  investigator  sought  information  from  DMOVT-AF  personnel 
experienced  in  MT  establishment  management's  insights  on  the  following: 

a.  definition  of  variables  and  procedures, 

b.  relationships  between  variables, 

c .  undocumentp'^  procedures , 

d.  if  the  information  could  be  organised  in  a  different  manner  that 
would  be  better  suited  to  automation, 

e.  unusual  cases  that  would  test  the  system, 

f.  v^at  is  being  done  to  improve  efficiency  of  data  processing  at 
DMOVT-AF,  and 

g.  priorities  for  development. 

Relationships  and  procedures  were  documented  in  the  data 
dictionary  created  in  dBase  III  Plus^**.  Capturing  the  purpose  of  each 
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attribute  along  with  the  source  of  the  data  and  the  requirement  for  its 
inclusion  proved  invaluable  for  later  reference. 

Although  data  definitions  were  agreed  with  the  user  prior  to 
canmencement  of  coding  the  application,  approximately  five  percent  of 
the  definitions  required  adjustment.  These  adjustments  facilitated  data 
capture  and  normally  dealt  with  the  attribute's  size. 

The  databases  provide  a  means  of  organising  the  information  in 
such  a  way  that  it  will  be  easy  to  access  and  maintain.  Rather  than 
requiring  access  to  many  different  Defence  instructions,  information  was 
normalized  into  14  databases.  Figure  9  depicts  a  graphical 
representation  of  the  relationships  between  these  entities. 

Customer  Element  (CUSTEL.DBF) .  This  entity  contains 
information  about  an  element  of  a  unit  that  requires  MT  support  and  has 
been  allocated  an  establishment  authority.  This  entity  would  normally 
refer  to  a  RAAF  organisational  element  known  as  a  section;  for  example 
"Aircraft  Refueling  Section". 

Customer  Unit  (CUSTUNIT.DBF) .  Information  pertaining  to  the 
parent  unit  of  custaners  that  requires  MT  support  would  normally  equate 
to  a  RAAF  squadron. 

Pep 1 oyment  Category  ( DEPLOY . DBF ) .  This  entity  contains 
information  about  restrictions  regarding  the  deployment  of  vehicles. 

Establishment  Authority  (ESTAUTH.DBF) .  Authorised 
establishments  previously  represented  on  a  word  processor  are  contained 
in  this  entity.  Each  record  represents  a  line  on  an  establishment 
table. 

Establishment  Type  (EST  TYPE. DBF).  This  entity  details  the 
different  classifications  of  establishments  to  which  an  establishment 
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Figure  9.  Establishment  Entity  Relationshi  . iagram 


table  may  be  grouped.  Vehicle  establishments  allocated  to  RMSs  usually 
belong  to  "UE"  --  unit  establishment. 

Establishment  Variation  Request  (EVR.DBF).  An  Establishment 
Variation  Request  (EVR)  is  the  means  by  active  units  to  apply  for 
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variations  of  an  MT  establishment.  This  entity  contains  Leader 
information  frcan  an  EVR. 

Establishment  Variation  Recruest  --  Offset  (EVR  OFF. DBF). 
Details  of  what  establishment  authorities  would  be  offset  in  lieu  of  a 
proposed  increase  on  an  MT  establishment  variation  request  are  contained 
as  records  in  this  entity. 

Establishment  Variation  Request  --  Variation  (EVR  VAR. DBF). 
This  entity  details  the  variation  requested  against  an  establishment 
authority  or  the  number  of  vehicles  for  a  new  establishment  authority. 

Establishment  Table  (E  TABLE. DBF).  An  establishment  table 
represents  a  grouping  of  establishment  authorities  for  management 
purposes.  An  establishment  table  usually  represents  a  geographic  area 
and  relates  to  one  establishment  unit.  This  entity  contains  the  header 
information  for  a  group  of  establishment  authorities. 

Establishment  Unit  (E  UNIT. DBF).  Units  are  responsible  for 
local  management  of  the  IfT  establishment  and  for  provision  of  MT 
services.  This  vjould  usually  be  a  Base  Squadron  or  Supply  Support 
Squadron  containing  an  RMS.  E-UNIT. DBF  provides  information  about  that 
unit . 

Mobi  1  i ty  Category  (NtOBILITY.DBF) .  Mobility  restrictions 
apply  to  many  role  codes  that  represent  vehicle  types.  MOBILITY. DBF 
represents  a  table  of  these  mobility  restrictions. 

Role  Annotation  (R  ANNOT.DBF).  Special  criteria  exists  for 
establishment  of  a  vehicle  type  or  role.  This  entity  provides  a  table  of 
authorised  role  annotations  that  detail  the  criteria. 

Surface  Vehicle  Category  (SV  CAT. DBF).  Vehicle  types  or 
roles  are  generically  group^ed  for  management  purposes;  for  example, 
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refueling  vehicles  or  passenger  carrying  vehicles,  SV-CAT.DBF 
represents  a  table  of  this  grouping. 

Vehicle  Role  Codes  (VEH  ROLE. DBF).  This  entity  details 
information  about  a  specific  classification  of  vehicle.  This 
classification  is  known  as  a  role  code  and  is  a  subset  of  a  larger 
surface  vehicle  category.  An  example  is  a  light  sedan  or  a  5  tonne 
general  service  truck.  This  entity  also  contains  information  pertinent 
to  the  establishment  and  replacement  criteria  applicable  to  each  role 
code  plus  other  management  information. 

Figure  9  illustrates  the  relationship  betv/een  these  entities.  The 
corresponding  EA  list  to  this  model  is  attached  at  ;^pendix  C.  The  data 
dictionary,  v^^iich  explains  each  data  attribute,  is  at  /s^jpendix  B.  The 
data  to  be  stored  in  the  databases  represents  the  possible  core  for  many 
other  applications.  Many  of  the  elements  maintained  on  the  databases 
are  not  yet  accessed  by  the  reports  in  the  application. 

Forty  international  telephone  calls  accounted  for  the  majority  of 
communication  between  the  investigator  and  the  user.  This  represented  a 
cost  of  approximately  $US850.00  to  the  Australian  Government.  Where 
practical,  a  facsimile  machine  was  used.  Due  to  clarity  of  the  final 
product  or  volume  of  documentation,  mail  had  to  be  relied  on.  Mail 
packages  sometimes  took  14  days  to  reach  the  user.  This  tyranny  of 
distance  was  ccanpounded  by  time  zones  and  other  work  priorities  for  both 
the  user  and  the  investigator. 

The  Event  List  v/as  a  difficult  concept  to  convey  to  the  user  and 
the  final  list  represents  internal  as  well  as  external  events.  VJhile 
the  user  had  some  exposure  to  DFDs,  these  were  difficult  to  transmit  by 
facsimile  machine  and  explain  by  telephone.  Nevertheless,  both  tools 
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were  useful  in  definition  of  the  broad  scope  and  for  providing  the  basis 
of  a  target  document.  Close  proximity  would  have  allowed  the 
investigator  to  be  present  with  documentation  and  examples  of  processes 
and  screen  designs.  This  would  have  allowed  quicker  development  of 
interfaces  and  features. 

All  the  code  generating  software  used  by  the  investigator  relied 
on  database  definitions  for  code  generation.  The  investigator's 
intention  ^■Tas  to  eliminate  amendments  to  these  data  definitions  prior  to 
coding  the  applications.  In  hindsight,  less  emphasis  could  have  been 
placed  on  developing  the  definitions  and  more  time  spent  on  early 
prototyping  and  screen  design.  'This  v/ould  have  resulted  in  greater  user 
participation  and  motivation  in  the  early  stages  of  the  project,  v;hile 
resolving  the  data  definitions  problems  that  could  not  be  foreseen  v-^ien 
definitions  were  restricted  to  the  data  dictionary.  This  approach  vjould 
have  been  more  suitable  if  the  investigator  and  user  v;ere  in  closer 
proximity. 

A  draft  user  manual  explaining  the  features  of  the  system  and 
including  screen  captures  would  have  provided  a  more  suitable  target 
document  for  this  application.  This  would  have  provided  the  user  with  a 
clearer  appreciation  of  the  capabilities  of  the  application.  In  the 
endeavour  to  document  data  requirements,  this  method  was  overlooked  by 
the  investigator. 

Research  Question  Four. 

vJhich  data  processes  and  information  requirements  can  be 

improved  by  using  a  microcomputer  database  application? 

Many  areas  of  the  management  of  RAAF  ITT  have  been  identified  for 
possible  automation.  The  data  processes  that  required  automating  v/ere 
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identified  in  the  Event  List  agreed  with  the  user.  All  the  processes 
centered  around  the  ability  to  add,  edit,  and  delete  records  on  the 
databases  plus  the  ability  to  produce  reports  from  that  information. 

Additional  Flexibility.  One  of  the  major  criticisms  of  the 
current  system  was  its  inability  to  retrieve  data  in  a  timely,  flexible 
manner.  As  documented  in  the  E'/ent  List  that  forms  part  of  the  Target 
Document,  the  user  requested  additional  flexibility  in  viewing  the 
establishment.  The  fol laving  reports  provide  for  this  need: 

a.  OT  Establishments  by  Mobility  and  Role  Codes, 

b.  OT  Establishments  by  Self  Deployment  Category  and  Role  Codes, 

c.  MT  Establishment  Listing  by  Customer  Unit  and  element, 

d.  Role  Annotations, 

e.  Self  Deployment  Categories, 

f .  Mobi 1 i ty  Categor i es , 

g.  All  establishment  types  (Event  List,  Items  12  through  14),  and 

h.  Amendments  to  establishment  tables. 

The  following  reports  were  omitted  due  to  time  constraints: 

a.  ITT  Establishments  by  Supply  Source  Classification  and  Role  Codes 
(Event  List,  Item  15), 

b.  I-rr  Establishment  Tables  for  each  Establishment  Unit  by  Command 
(Event  List,  Item  16),  and 

c.  NTT  Establishment  Tables  for  each  Customer  Unit  by  Command  (Event 
List,  Item  16) . 

Even  v/ithou*  the  inclusion  of  the  last  three  reports,  the  database 
application  provides  for  far  more  flexibility  than  v/as  available  from 
the  v«3rd-processed  establishment  tables,  manual  files,  or  Defence 
Instructions. 
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During  loading  of  the  databases,  the  application  illustrated  its 
ability  to  improve  the  accuracy  of  data  records  by  highlighting  errors 
of  duplication  in  the  current  records. 

Research  Question  Five. 

Can  appropriate  ccarrputer  programs  be  generated  to  meet  those 
user  requirements  assessed  as  being  most  appropriate  for 
autcmiation? 

As  discussed  in  the  answer  to  Question  4,  clipper**  application  programs 
were  generated  to  meet  the  requirements  stated  on  the  Target  Document. 
Figures  4  through  8  provide  an  overview  of  the  programs  that  form  the 
application. 

Code  required  for  these  functions  exceeds  500  pages.  Due  to  its 
size,  the  computer  program  code  for  the  application  has  not  been 
included  in  printed  form  in  this  thesis.  A  copy  of  the  source  code  is 
available  on  5.25  inch  disk  format.  The  User  Manual  at  i^pendix  D 
provides  a  detailed  explanation  of  the  features  of  the  application.  The 
fol laving  represent  scane  of  the  features  that  were  included; 

Pull-down  Menus.  Pull-down  menus  have  been  installed  to 
allow  the  user  to  perform  functions  and  to  trace  a  path  back  to  higher 
levels.  There  are  two  ways  to  activate  a  selection: 

a.  highlight  the  option  by  using  the  cursor  or  arrow  keys  on  the 
keyboard,  or 

b.  press  the  highlighted  letter  of  the  selection  that  is  required. 

The  Help  Selection.  A  brief  explanation  of  functions  is 
provided  to  the  user  for  each  section.  The  Hell  election  from  the  main 
menu  provides  a  brief  summary  of  the  functions  of  each  section. 

Comments  are  provided  on  each  menu  to  assist  the  user.  Menus  in  Delete 
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and  Report  functions  provide  explanations  at  the  bottom  left  corner  of 
the  screen.  These  explanations  change  with  each  option  highlighted. 

For  more  information  about  each  function  of  ESTAB,  refer  to  the  user's 
manual,  i^spendix  D. 

Quitting  an  Operation.  Application  programs  were  designed 
so  that  the  escape  key  is  a  common  exiting  mechanism.  The  user  will  be 
prompted  for  data  entry  as  higher  level  menus  appear. 

Learning  versus  Development.  Since  the  investigator  was 
unaware  of  the  power  of  many  of  the  automated  development  tools,  such  as 
UI2^**,  it  was  difficult  to  forecast  what  could  reasonably  be  achieved 
within  the  available  time  line.  Learning  hov;  to  use  these 
unquestionably  valuable  software  generators  took  many  v/eeks  and  their 
full  potential  is  still  unknown.  Time  taken  for  sufficient  learning  v/as 
not  adequately  forecast  at  ccmmencement  of  the  thesis. 

Research  Question  Six. 

Hov7  can  the  application  be  validated  to  ensure  successful 
implementation  and  acceptance  by  users? 

Phase  6  evaluated  the  new  application  of  the  methodology.  Selected  AFIT 
personnel  were  requested  to  perform  a  technical  review  of  the 
application  (Fogg,  1990;  Noble,  1990;  Beard,  1990).  DMOVT-AF  assessed 
the  usefulness  and  acceptance  of  the  system.  Interviev/s  with  personnel 
who  have  been  exposed  to  the  application  formed  the  basis  for  data 
collection  (Haren,  1990). 

Evaluation  (Acceptance  Test) .  In  evaluating  ESTAB,  DMOVT- 
AF  v/as  asked  to  consider  speed  and  accuracy  of  the  process,  and  access 
to  information. 
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The  following  tasks  were  identified  as  being  accomplished  with 
ESTAB  in  minutes,  vAien  they  each  previously  took  bet\>/een  two  hours  and 
two  days: 

1.  accessing  establishment  data, 

2.  analysing  establishment  types, 

3.  reviewing  fleet  composition, 

4.  review  of  fleet  distribution, 

5.  updating  establishment  data,  and 

6.  identifying  vehicle  role  code  data  v^iich  v;as  spread  through  many 
documents. 

Manually  producing  the  Consolidated  MT  Summary  was  estimated  to 
have  taken  up  to  two  weeks  and  could  not;  be  achieved  in  fifteen  minutes. 

ESTAB  improved  the  accuracy  of  information  as  it  avoided 
duplication  of  data  and  provided  cross  checking  of  tables.  Data 
previously  stored  at  IMDVT-AF  in  word-processed  and  manual  files  vras  nav 
in  a  relational  database  format.  The  use  of  a  relational  DBMS  provides 
a  compact  and  efficient  storage  media.  DMOVT-AF  considered  ESTAB  to  be  a 
vast  improvement  in  accessing  information  on  current  systems  through  the 
use  of  a  composite  database  (Haren,  1990). 

Despite  the  success  of  the  application,  the  user  identified  a 
n'jmber  of  improve”  nts  that  would  make  ESTAB  more  effective,  user 
friendly,  and  assist  in  decision  support.  To  improve  effectiveness  in 
assisting  management  of  RAAF  MT  assets,  ESTAB  should  be  enhanced  to 
include  the  follov/ing: 

a.  a  form  letter  for  the  front  of  the  establishment  tables  to  reflect 
the  latest  amendments  to  that  establishment  table; 
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b.  ad-hoc  query  function  to  allow  identification  of  establishments  that 
meet  certain  criteria  in  the  form  of  a  structured  query  language  and 
report  writer; 

c.  inclusion  of  conmand  and  geographic  groupings  of  establishments  to 
allow  reporting  in  this  manner; 

d.  consolidated  summary  of  establishment  amendments  by  role  code, 
unit  and  value  to  allcw  trend  analysis  and  constant  monitoring;  and 

e.  sub-totals  for  each  role  code  on  the  individual  unit  establishment 
table  reports. 

iVhile  the  user  considered  the  pull  down  menus  and  other  aspects  of 
ESTAB  very  helpful,  the  following  features  would  enhance  the 
application's  user  friendliness: 

a.  inclusion  of  an  ad-hoc  query  feature  to  allow  selective  viewing  of 
database  contents; 

b.  greater  flexibility  with  report  generation  associated  vhth  ad-hoc 
queries; 

c.  selective  reporting  of  the  Consolidated  ITT  Summary  Report  by 
individual  role  codes  as  the  current  format  would  be  too  large  for  a 
fully  loaded  database  (95  role  codes  x  22  possible  establishment  units). 
The  user  also  requested  a  total  summary  report  by  role  code,  but 
excluding  the  establ i .shment  unit  detail;  and 

d.  inclusion  of  date  data  showing  when  the  estimated  replacement  price 
(ER-PRICE)  on  the  vehicle  role  code  record  was  updated,  as  this  data  is 
not  subject  to  amendment  list  control. 

The  requirements  for  selective  consolidated  MT  Summary  reporting 
and  ER-PRICE  field  update  were  met  with  version  1.3  of  ESTAB.  After 
seeing  the  capability  of  ESTAB  to  organise  and  store  information,  the 
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user  saw  potential  for  decision  support  applications.  The  ability  to 
gather  similar  establishment  authorities  by  scxne  parameters  would  aid 
management  decisions.  Graphical  representations  would  be  especially 
suitable.  With  more  emphasis  on  financial  constraints,  a  decision 
support  system  (DSS)  capability  to  value  the  establishments  based  on  the 
estimated  replacement  cost  of  each  vehicle  role  would  be  very  useful. 
This  would  support  a  new  management  philosophy  of  delegating  the 
management  of  establishments  within  a  financial  ceiling  to  individual 
commands . 

Research  Question  Seven. 

Does  the  proposed  system  provide  improvements  in  efficiency 

vAien  compared  with  current  management  practices? 

Phase  6  of  the  methodology  attempted  to  quantify  any  improvements 
in  efficiency  as  a  result  of  implementing  the  application.  Telephone 
interviews  conducted  v/ith  the  same  group  from  Phase  l  resulted  in  the 
findings  discussed  under  Research  Question  6.  The  system  improved  the 
efficiency  of  I-fT  establishment  management  by  improving  the  speed  and 
accuracy  of  data  processing  tasks  associated  with  managing  the  P.AAF  OT 
establishment.  Data  is  also  more  readily  available  in  a  readable  format 
ready  for  direct  incorporation  into  Defence  Instructions,  and  as  stand¬ 
alone  reports  (Haren,  1990). 

Collection  and  analysis  of  user  requirements  usually  requires 
face-to-face  personal  interviews,  interaction,  and  observation. 
Attempting  this  task  from  another  country  is  unusual  and  did  prove  dif¬ 
ficult,  especially  when  modeling  user  requirements  not  previously  docu¬ 
mented.  These  problems  of  distance  and  communication  emphasise  the  re¬ 
quirement  for  rigor  and  accuracy  during  initial  data  gathering  and 
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specification  steps  of  this  project.  Time  did  not  allow  as  many 
iterations  of  the  review  process  in  the  formative  stages,  as  was 
desired.  However,  relatively  high  levels  of  accuracy  were  still 
achieved.  This  was  evidenced  by  the  subsequent  software  meeting  user 
requirements  and  improving  efficiency. 

Ihe  relational  database  organisation  provides  the  basis  for  many 
other  applications  and  has  reduced  the  duplication  of  data  to  minimal 
levels.  The  process  of  documenting  and  normalizing  the  database 
provides  the  user  with  the  information  source  for  each  data  attribute 
(see  Appendix  B) . 

The  user  expects  to  complete  loading  the  current  database  and  have 
ESTAB  fully  implemented  by  December  1990.  The  full  impact  of  improved 
efficiency  at  IMDVT-AF  will  be  easier  to  appreciate  following  full 
implementation  of  ESTAB. 

Summary 

This  chapter  simimarised  the  findings  to  research  questions  3 
through  7. 

Research  Question  Three. 

What  are  the  data  processing  and  information  requirements 

for  executive  level  RAAF  MT  asset  management? 

The  data  processes,  relationships,  and  information  that  form  this 
application  can  be  seen  as  only  a  small  element  of  v^at  would  comprise  a 
larger  integrated  MIS.  The  establishment  management  information 
gathered  reflects  E^-lOVT-AF's  concentration  on  higher  level  policy  and 
establishment  issues. 
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A  Target  Document,  exploring  the  goals  of  the  project,  was 
developed  and  agreed  with  the  user.  A  large  ER  diagram,  illustrating 
the  relationships  of  the  data  developed  for  establishment  management  at 
CMOVT-AF  and  that  of  a  larger  MIS  was  developed.  Selected  systems 
analysis  tools  expressed  user  requirements  as  models  of  processes,  data 
relationships,  and  data  definitions.  These  were  developed  into  a 
Clipper^**  application  program  and  14  relational  databases. 

Research  Question  Four. 

Which  data  processes  and  information  requirements  can  be  improved 
by  using  a  microcomputer  database  application? 

Many  areas  were  identified  for  automation.  The  processes  with  the 
most  potential  to  improve  efficiency  at  IM)VT-AF  were  agreed  via  the 
Target  Document.  These  processes  centered  around  the  ability  to  add, 
edit,  delete,  and  report  information  about  MT  establishments. 

With  the  exception  of  three,  all  reports  identified  in  the  Target 
Document  were  developed.  Inflexibility,  one  of  the  major  criticisms  of 
the  current  system,  v;as  addressed  by  the  development  of  the  relational 
database  and  these  reports.  Data  accuracy  was  improved  by  eliminating 
duplication  data  via  error  routines  in  the  application. 

Research  Question  Five. 

Can  appropriate  computer  programs  be  generated  to  meet  those  user 
requirements  assessed  as  being  most  appropriate  for  automation? 
Blueprints  of  data  relationships  and  processes  were  developed  into 
databases  and  Clipper^**  programs.  A  structured  programming,  top-down 
approach  was  used  to  develop  modules  to  interact  with  the  normalised 
database.  Techniques  v/ere  developed  to  protect  data  integrity  and 
enhance  user-friendliness.  UI2^**  and  Relational  Report  VJriter™  program 
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code  generators  were  used  to  generate  a  large  amount  of  the  NTT 
establishment  management  information  system  (ESTAB)  application. 

Learning  how  to  use  these  powerful  tools  required  many  weeks  and  their 
full  potential  remains  unknown.  Revisions  of  the  application  vjere 
forwarded  to  Australia  for  user  evaluation. 

Research  CXjestion  Six. 

How  can  the  application  be  validated  to  ensure  successful 
implementation  and  acceptance  by  users? 

Cases  based  on  user  requirements  were  generated  to  test  versions 
of  ESTAB  before  they  were  di spatched  to  the  user .  Phase  6  of  the 
methodology  evaluated  ESTAB  using  selected  AFIT  personnel  and  CMOVT-AF 
staff.  The  application's  abilities  were  compared  to  the  Target  Document 
developed  in  Phase  1.  EMOVT-AF  was  asked  to  consider  speed  and  accuracy 
of  the  process,  and  access  to  information.  The  user  stated  that  ESTAB 
had  met  his  original  requirements  but  stated  a  number  of  improvements 
would  enhance  ESTAB.  Some  of  these  enhancements  were  incorporated  in 
version  1.3  of  the  application. 

Research  Question  Seven. 

Does  the  proposed  system  provide  improvements  in  efficiency  VN^en 
compared  with  current  management  practices? 

The  user  assessed  that  ESTAB  improved  the  efficiency  of  MT 
establishment  management  by  improving  the  speed  and  accuracy  of  data 
processing  tasks  associated  with  managing  the  RAAF  OT  establishment. 

Data  v/as  also  more  readily  available  in  a  readable  format  ready  for 
direct  incorporation  into  Defence  Instructions,  and  as  stand-alone 
reports. 
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V.  Conclusions  and  Recommendations 


Introduction 

Ttiis  chapter  summarises  the  results  of  the  research  and  recommends 
areas  for  follow  on  studies. 

Summary 

Ttie  goal  of  this  research  was  to  develop  and  evaluate  a 
microcomputer  application  vAiich  would  improve  efficiency  in  data 
processing  and  management  of  the  RAAF  MT  fleet  at  DMOVT-AF.  According 
to  user  response,  the  goal  of  producing  a  successful  prototype  v;as 
achieved.  The  Motor  Transport  Establi.5hment  Management  Information 
System  (ESTAB)  includes  a  converted  database  and  user  accepted 
application  programs. 

ESTAB  improved  the  efficiency  of  OT  establishment  management  by 
improving  the  speed  and  accuracy  of  data  processing  tasks  associated 
with  managing  the  RAAF  MT  establishment.  Data  v/as  also  more  readily 
available  in  a  readable  format  ready  for  direct  incorporation  into 
Defence  Instructions,  and  as  stand-alone  reports.  Version  1.3  of  the 
application  v/as  implemented  at  EM3VT-AF  on  19  July  1990.  IHDVT-AF  staff 
v/ill  complete  database  conversion  and  plan  to  have  ESTAB  fully 
operational  by  December  1990. 

The  user  stated  that  ESTAB  had  met  his  original  requirements,  but 
stated  a  number  of  improvements  vAould  enhance  ESTAB.  While  some 
enhancements  v/ere  incorporated  in  Version  1.3  of  the  application, 
satisfaction  of  other  requirements  v/ill  require  further  research. 
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Recommendations  for  Further  Research 

Recc^ranendations  for  further  research  focuses  on  four  areas: 

a.  improving  ESTAB  to  reflect  additional  user  requirements, 

b.  autcanating  vehicle  despatch  and  administration  functions  to  base 
Road  Movement  Sections  (RMS), 

c.  automating  the  processing  of  establishment  variation  requests,  and 

d.  developing  decision  support  systems  at  all  levels  of  MT  management. 

Improving  the  ESTAB  Application.  The  scope  of  the  thesis  v;as 
limited  by  time.  Chapter  4  lists  a  ntunber  of  features  that  the  user 
v/ould  like  to  see  included  in  ESTAB.  The  database  would  need  to  be 
expanded  to  accommodate  these  changes. 

New  management  practices  concentrating  on  financial  information 
and  related  to  program  budgeting  are  being  developed.  ESTAB  will  need 
to  be  enhanced  once  those  procedures  are  finalised. 

ESTAB  can  be  used  to  add,  edit,  delete,  and  report  OT 
establishment  information.  The  relational  database  invites  the 
development  of  other  applications  at  DMOVT-AF  to  utilize  all  included 
data. 

Autonating  Rl^tS  Vehicle  Despatch  and  Administration .  Research 
illustrated  that  efficiency  benefits  v/ill  also  occur  if  applications  are 
developed  for  lower  MT  asset  management  areas.  The  daily  functions  of 
an  RMS  are  data  intensive.  Vehicle  fleets  of  over  200  vehicles  must  be 
coordinated  and  despatched  daily.  Data  records  are  all  manually 
maintained  and  reports  for  higher  management  levels  must  be  hand 
generated.  The  ITT  management  information  entity  relationship  diagram  at 
Appendix  E  illustrates  the  important  data  groupings  that  may  be  included 
in  such  a  system.  This  system  v/ould  need  to  interface  v/ith  ESTAB  to 
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allow  access  to  establishment  information  and  provide  DMOVT-AF  and 
Commands  with  valuable  usage  data. 

Automation  of  Establishment  Variation  Recaiests.  Ttie  rational  for 
the  initial  establishment  of  numbers  of  vehicles  for  a  vehicle  type  is 
recorded  on  paper  files  and  cannot  be  retrieved.  Custcaner  units  are 
often  required  to  re- justify  the  requirements  for  establishment  in  times 
of  verification  or  query  of  entitlement.  This  places  an  unnecessary 
burden  on  all  levels  of  management  involved  in  the  collection  and 
analysing  process.  Additionally,  the  lack  of  access  to  this  information 
deprives  all  levels  of  OT  management  of  information  necessary  for 
control  of  vehicle  use.  Vehicles  are  often  employed  for  purposes  for 
v;hich  they  were  not  intended.  Staff  turnover,  at  all  management  levels, 
coupled  with  the  poor  accessibility  of  establishment  variation  request 
(EVR)  information  allows  this  information  to  be  lost  over  time.  Capture 
of  this  information  on  a  retrievable  media  at  the  time  of  EVR  sutmission 
vjould  also  assist  tracking  of  sutmission  and  allov;  answering  of 
processing  status  queries.  Developwent  of  the  facet  of  a  complimentary 
system  to  ESTAB  is  feasible  once  data  processing  at  the  RIIS  level  has 
been  automated.  Development  before  this  important  step  vADuld  mean 
unnecessary  data  entry  and  lessen  system  data  integrity.  Eventually 
such  a  system  may  allow  desk-top  review  of  establishments  using  RIIS 
supplied  data  and  establishment  usage  requirements  by  vehicle  type. 

Developing  DSSs.  All  DSSs  require  a  database  (Davis,  1988:75). 
Models  can  be  developed  to  analyse  this  information  and  assist  decision 
malang.  The  area  of  expert  systems  provides  great  potential  for  use  of 
this  data  in  conjunction  with  heuristics  to  aid  management.  A  prototype 
system  using  the  ESTAB  database  v;as  developed  by  the  investigator  using 
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VP-EXPE]RT^  software  (Holden-Day,  1988).  The  Establishment  Valuation 
Request  Advisor  (EVRA)  illustrated  the  ability  to  develop  input  systems 
that  emulate  human  expertise  and  allow  that  expertise  to  be  shared 
throughout  an  organisation.  Many  other  applications  could  be  developed 
at  all  levels  of  MT  asset  management  along  similar  lines. 

User  interfaces  that  utilize  graphics  could  be  used  to  enhance 
views  of  current  information  managed  by  ESTAB  and  allow  v/hat-if 
calculations.  Use  of  a  structured  query  language  in  conjunction  with 
this  form  of  interface  would  provide  management  with  a  powerful  tool  for 
decision  making. 
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Appendix  A:  Target  Document 


Hiis  document  describes  the  details  of  the  project  life  cycle  and 
the  agreed  goal  and  objectives  of  the  nev/  system.  Details  of  the 
project  life  cycle  v/ere  transmitted  via  a  copy  of  the  draft  methodology. 
Details  v;ere  updated  via  telephone  conversations. 

The  Target  Docimient  was  developed  frcm  the  initial  context  DFD  at 
Figure  A-1  and  event  list  at  Table  A-1.  It  represents  an  agreement 
between  the  user  and  the  investigator  of  v-Aiat  should  be  included  in  the 
project  scope. 

The  Initial  Context  DFD  represented  the  information  requirements 
of  the  proposed  system  as  they  relate  to  the  organisational  elements 
defined  in  Chapter  II.  The  Event  List  was  a  narrative  list  of  all  the 
events  that  occur  outside  the  system  to  vAiich  the  system  must  respond. 

Scope.  The  investigator  and  user  agreed  on  the  scope  of  the 
project  throughout  the  use  of  a  Context  Diagram  and  Event  List.  The 
thesis  will  only  address  the  establishment  management  requirements  for 
DMOVT-AF  and  not  those  of  SG3.  The  agreed  requirements  for  ESTAB  are 
detai  led  belot-/. 

Data  Maintenance  Functions.  ESTAB  is  to  provide  the  ability  to 
add,  modify,  and  delete  all  establishment  data  including  the  fol laving: 

a.  establ i.shment  tables, 

b.  surface  vehicle  categories, 

c.  vehicle  role  codes  and  their  policy  details, 

d.  mobility  categories, 

e.  sel f -deployment  categories. 
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Event  List 


1.  HQLC  (AEENG5)  modifies  the  role  of  a  vehicle  type.  (F) 


2.  An  Air  Force  Operational  Directive  (AFOD)  issued  by  Air  Force 
Office  creates  a  new  unit  (customer)  which  requires  MT  support. 

(P) 

3.  Air  Force  Office  issues  an  AFOD  v^ich  disbands  a  unit  (customer) 
established  for  OT.  (F) 

4.  A  customer  unit  places  an  EVR  through  its  establishment  unit  and 
parent  command  to  alter  its  vehicle  establishment.  (F) 

5.  A  customer  queries  what  vehicles  are  established  for  its  use.  (F) 

6.  Air  Fore  Office  changes  a  customer  unit's  host  establishment  unit. 


7.  A  Command,  RMS  or  customer  unit  asks  about  the  status  of  an  EVR. 
(F) 

8.  Air  Force  Office  asks  details  abou  a  vehicle  type.  (F) 

9.  Air  Force  Office  changes  the  location  of  an  establishment  unit. 

(F) 

10.  Air  Force  Office  adds  a  nev^/  mobility/deployment  requirement  for 
vehicles.  (F) 

11.  The  ADF  deletes  a  mooi 1 ity/Feployment  requirement  for  vehicles. 

(F) 

12.  A  new  establishment  type  is  established  by  Air  Force  Office 
policy.  (F) 

13.  An  existing  establishment"  type  is  modified  by  the  Air  Force  Office 
policy.  (F) 

14.  An  existing  establishment  type  is  deleted  by  ATF  policy.  (F) 

15.  HQADF  (ACLOG)  v;ants  to  knov;  v^iere  all  the  vehicles  of  a  supply 

source  classification,  such  as  commercial  line,  are  established 

and  vThat  are  their  tasks.  (F) 
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Table  A-1  (Cont'd) 


i 


Item  Description 

16.  A  RMS  requests  a  printout  of  their  establishment.  (F) 

17.  SG3  requires  an  annual  listing  of  all  vehicle  types  established 
by  location.  (T) 

Legend; 

(T)  denotes  temporal  events.  These  are  events  triggered  by  the  passage 
of  time. 

I 

(F)  denotes  flow-orientated  events.  These  are  events  caused  by  the 
arrival  of  some  infonnation  to  the  system. 


f.  establishment  role  restrictions  or  annotations  for  vehicle  roles, 

g.  customers  allocated  vehicles,  and 

h.  units  authorised  to  hold  and  manage  establishments. 

Output .  ESTAB  is  to  provide  reports  --  display  and  print  --  of 
all  current  reports  required  by  DMOVT-AF.  (The  numbers  refer  to  the 
Event  List  reference.)  Specifically  the  following: 

a.  ITT  Establishment  Tables  for  each  Establishment  Unit  (16) 

b.  Consolidated  listing  of  all  establishments  by  Role  Code  (18,19), 

c.  tfT  Establishment  and  Replacement  Criteria  (Annex  C  to  Chapter  15 
DI(AF)AAP  3635.001) . 

Additional  Flexibility.  Users  requested  additional  flexibility  i 
viewing  the  establishment.  The  follov/ing  reports  provide  for  some  of 
this  need: 

a.  I  IT  Establishments  by  Mobility  and  Role  Codes, 

b.  irr  Establishments  by  Self  Deployment  Category  and  Role  Codes, 

c.  irr  Establ  1  stiment  Listing  by  Ojstomer  Unit  and  element, 


d.  Role  Annotations, 

e.  Self  Deployment  Categories, 

f.  Mobility  Categories, 

g.  MT  Establishments  by  Supply  Source  Classification  and  Role  Codes 
(Event  List  Item  15), 

h.  MT  Establishment  Tables  for  each  Establishment  Unit  by  Conmand 
(Event  List  Item  16), i.  MT  Establishment  Tables  for  each  Customer  Unit 
by  Command  (Event  List  Item  16), 

j.  All  establishment  types  (Event  List  Items  12  through  14),  and 

k.  Amendments  to  establishment  tables. 


71 


Figure  A-1.  Initial  Context  Data  Flow  Diagram 
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Appendix  B:  Establishment  MIS  Data  Dictionary 


Introduction 

The  following  list  is  the  data  dictionary  of  the  Establishment 
Management  Information  System  (ESTAB) .  It  was  developed  using  Aston 
Tate's  dBase  III  Plus^**.  The  report  was  generated  using  Relational 
Report  Writer^*  software  and  represents  all  the  data  elements  or  fields 
used  in  the  application.  An  explanation  of  the  terms  follows. 

"Data  attribute  name"  is  the  abbreviated  name  of  lo  characters 
used  in  Clipper^^  programs  and  associated  databases.  "Format"  denotes 
the  form  of  allowable  character  representation  in  the  database.  A 
numeric  field  is  denoted  by  a  "9".  An  "A"  denotes  only  alphabetic 
characters.  Any  character  is  denoted  by  an  "X".  The  number  in 
parenthesis  that  follows  these  symbols  denotes  the  number  of  that  type 
of  character;  for  example  "99"  is  the  same  as  ”9(2)".  An  "S"  denotes 
that  positive  and  negative  values  must  be  represented.  A  "V"  denotes 
positioning  of  the  decimal  point  for  numeric  values. 

"Full  name"  is  the  canmon  title  of  the  attribute.  "Description" 
is  a  short  description  of  the  field  contains.  The  "Dcmain"  represents 
the  valid  values  expected  at  the  time  of  input  or  update  of  that 
attribute.  "None  specified"  in  this  area  means  that  no  specific  values 
v/ere  specified  for  validation  purposes. 

The  "Purpose"  of  the  data  attribute  denotes  why  it  vias  included  in 
the  database  and  application.  "Ent i ty "  denotes  where  the  data  attribute 
resides  in  the  database  folla-nng  the  developmental  process  of 
normalization.  V/here  data  attributes  act  as  links  or  keys  to  other 
entities  and  their  attributes,  the  data  attribute  will  be  repeated. 
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This  redundaiic’y  is  necessary  to  allcw  the  representation  of 
relationships  between  data  groups.  When  a  data  attribute  acts  in  this 
manner,  "Purpose"  will  denote  that  it  is  a  "foreign  key"  to  another 
entity.  When  an  attribute  is  used  to  uniquely  identify  an  occurrence  of 
an  entity,  it  is  referred  to  as  a  "primary  key". 

"Source  of  the  data  requirement"  denotes  v^ere  the  requirement  to 
include  the  attribute  originated.  "Source  of  raw  data"  denotes  v^ere 
the  current  data  can  be  found  to  convert  to  the  new  database. 


Data  Dictionary  of  Attributes  in  Alphabetical  Sequence 


Data  Attribute  Name:  AIRPORTABI  Format :  X(3) 

Full  Name;  Airportabi lity 

Description:  Indicates  whether  airportabi 1 ity  is  mandatory  or  not  for  a 
particular  role  code. 

Domain:  yes, no 

Purpose:  Allows  management  of  vehicle  airportabi 1 ity  by  role  code. 
Entity:  VEH_ROLE 

source  of  data  requirement:  DI(AF)AAP7070.014  paragraph  lio  ALl 
Source  of  raw  data  for  database;  DI(AF)AAP7070.014  paragraph  (Chapter  4 
ALl 


Data  Attribute  Name:  CAMOUFLA®  Format:  X(3) 

Full  Name:  approval  for  Camouflage 

Description:  Indicates  if  Air  Force  Office  (DMOVT-AF)  has  approved 
application  of  camouflage  colours  to  the  role  code. 

Domain:  yes, no 

Purpose:  Allows  standard  management  of  canrauflage  by  role  code. 
Entity:  VEH_ROLE 

Source  of  data  requirement:  DI(AF)AAP7070.014  paragraph  113 
Source  of  raw  data  for  database:  DI(AF)AAP7070.014  Chapter  4 


Data  Attribute  Name:  CM)_REF  Format:  X(40) 

Full  Name:  Command  File  Reference 

Description:  The  file  reference  used  by  the  parent  ccanmand  in 
correspondence  relating  to  the  EVR. 

Domain:  None  specified 

Purpose:  Allo^/s  cross-referencing  of  correspondence  to  EVRs. 
Entity:  EVR 

Source  of  data  requirement:  DI(AF)AAP3631.00l  Chapter  15 
Source  of  rav;  data  for  database:  EVRs,  Ccsnmands 
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Data  Attribute  Name:  OJSTATDRES  Format :  X{50) 

Full  Name:  Custcxner  Address 

Description:  The  address  of  the  customer  unit  requesting  transport 
support  services  or  assets. 

Domain:  None  specified 

Purpose;  Identifies  the  location  for  mailing  correspondence  of  a  unit 
requesting  support. 

Entity:  CUSTUNIT 

Source  of  data  requirement;  EMDVT-AF 

Source  of  raw  data  for  database:  DI(AF)AAP  5131.001 


Data  Attribute  Name;  aJSTEL_ID  Format:  X(15) 

Full  Name;  Customer  Element  Identifier 

Description:  A  term  used  to  uniquely  identify  a  customer  unit  element. 
Donain:  None  specified 

Purpose:  Allows  unique  identification  of  customer  elements  within  a 
unit . 

Entity;  CUSTEL 

Source  of  data  requirement;  EWOVT-AF 

Source  of  raw  data  for  database;  EVR  annotations 

Data  Attribute  Name:  CUSTEL_ID  Format :  X(15) 

Full  Name:  Customer  Unit  Element  Identifier 

Description;  A  term  used  to  uniquely  identify  a  customer  unit  element. 
Donain;  None  specified 

Purpose;  Denotes  the  unit  element  that  requires  the  EVR  offset. 
Entity:  EVR_0FF 

Source  of  data  requirement;  DMOVT-AF 
Source  of  raw  data  for  database;  IM)VT-AF 


Data  Attribute  Name:  CUSTBL_ID  Format;  X{13) 

Full  Name;  Customer  Element  Identifier 

Description;  A  term  used  to  uniquely  identify  a  customer  unit  element. 
Donain:  None  specified 

Purpose:  Denotes  the  customer  unit  for  the  establishment  authority. 
Entity;  ESTAUTO 

Source  of  data  requirement:  CMOVT-AF 
Source  of  raw  data  for  database:  IMDVT-AF 


Data  Attribute  Name:  CUSTEL_ID  Format :  X(15) 

Full  Name:  Customer  Element  Identifier 

Description:  A  term  used  to  uniquely  identify  a  customer  unit  element. 
Domain:  None  specified 

Purpose:  Identifies  unit  element  that  requires  EVR-offset. 

Entity:  EVR_0FF 

Source  of  data  requirement:  DMOVT-AF 
Source  of  rav;  data  for  database:  ra^lOVT-AF 
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Data  Attribute  Name:  ajSTEL_ID  Format :  X(15) 

Full  Name:  Customer  Unit  Element  Identifier 

Description:  A  term  used  to  uniquely  identify  a  customer  unit  element. 
Dcxnain:  None  specified 

Purpose:  Part  of  the  primary  key  of  EVR  to  vi^ich  the  variation  belongs. 
Entity:  EVR_\/AR 

Source  of  data  requirement:  DMOVT-AF 
Source  of  raw  data  for  database:  EMDVT-AF 


Data  Attribute  Name:  CUSTEL_NAM  Format :  X(30) 

Full  Name:  Custaner  Element  Name 

Description:  The  full  name  of  the  element  of  a  unit  that  requires  MT 
support . 

Danain:  None  specified 

Purpose:  Allcws  confirmation  of  selection  of  customer  element 
abbreviations. 

Entity:  CUSTEL 

Source  of  data  requirement:  EMDVT-AF 
Source  of  raw  data  for  database:  IM)VT-AF 


Data  Attribute  Name:  CUSTEL_PH  Format:  9(5) 

Full  Name:  Customer  Element  Phone  Extension 

Description:  The  telephone  extension  for  a  point  of  contact  at  the  unit 
element  requesting  transport  services  or  assets. 

Domain:  None  specified 

Purpose:  Allows  direct  contact  with  the  point  of  contact  at  the 
custcmer  unit. 

Entity:  CUSTEL 

Source  of  data  requirement:  raovT-AF 

Source  of  raw  data  for  database:  Custcxner  Unit 


Data  Attribute  Name:  CUSTROLE  Format:  X(30) 

Full  Name:  Customer  Unit  Role 

Description:  The  designated  role  of  the  customer  unit. 

Domain:  None  specified 

Purpose:  Identifies  the  roles  performed  by  the  custcmer  unit  that  may 
require  transport. 

Entity:  CUSTUNIT 

Source  of  data  requirement:  DMOVT-AF 
Source  of  raw  data  for  database:  ACD  171 
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Data  Attribute  Name;  CUSTU_SNAM  Format :  X{15) 

Full  Name;  Customer  Unit  Short  Name 

Description;  uniquely  identifies  a  military  unit  by  a  fifteen  letter 
short  name. 

Domain:  None  specified 

Purpose;  Denotes  the  parent  unit  of  a  custaner  element. 

Entity:  CUSTEL 

Source  of  data  requirement;  IM)VT-AF 
Source  of  raw  data  for  database;  Investigator 


Data  Attribute  Name:  CUS'IU_SNAM  Format:  X(15) 

Full  Name;  Custcmier  Unit  Short  Name 

Description:  Uniquely  identifies  a  military  unit  by  a  fifteen  letter 
.short  name. 

Domain;  None  specified 

Purpose;  Unit  requesting  Establishment  Variation  Request  (EVR). 
Entity:  EVR 

Source  of  data  requirement:  DI(AF)AAP3631.001  Chapter  15  Annex  A 
Source  of  raw  data  for  database:  DMOVT-AF 


Data  Attribute  Name;  CUSTU_SNAM  Format:  X(5) 

Full  Name;  Customer  Unit  Short  Name 

Description;  Uniquely  identifies  a  military  unit  by  a  fifteen  letter 
short  name. 

Domain:  None  specified 

Purpose:  Allows  requirements,  usage  and  requests  to  be  matched  to  a 
particular  unit. 

Entity;  CUSTUNIT 

Source  of  data  requirement;  IMDVT-AF 
Source  of  raw  data  for  database;  RMS/DMOVT-AF 


Data  Attribute  Name:  CUSTU_TITL  Format ;  X(30) 

Full  Name:  Customer  Unit  Full  Ti'le 

Description:  The  formal  title  of  a  unit  that  requires  MT  support. 
Domain;  None  specified 

Purpose;  Allows  recognition  of  a  unit  by  its  full  title. 

Entity;  CUSTUNIT 

Source  of  data  requirement;  EWOVT-AF 
Source  of  raw  data  for  database: 


Data  Attribute  Name:  CUST_ID  Format ;  x(5) 

Full  Name:  Customer  Unit  Designator  Code 

Description:  A  five  digit  code  that  uniquely  identifies  a  customer  unit. 
Domain:  None  specified 

Purpose :  Will  allow  identification  by  unique  ADF-wide  code. 

Entity:  CUSTUNIT 

Source  of  data  requirement:  EM)VT-AF 


Source  of  raw  data  for  database: 


Data  Attribute  Name:  DATE_E_AMD  Format:  dd/mm/yy 
Full  Name:  Date  Establishment  Table  Last  Amended 
Description:  The  date  the  establishment  table  was  last  amended. 
Domain:  None  specified 

Purpose:  Allows  recording  of  when  an  establishment  table  was  last 
updated. 

Entity:  EJTABLE 

Source  of  data  requirement:  EMOVT-AF 
Source  of  raw  data  for  database:  EWOVT-AF 


Data  Attribute  Name:  DATE_E_CRE  Format :  dd/mm/yy 

EMU  Name:  Date  Establishment  Table  Created 

Description;  The  calendar  date  that  the  establishment  table  was  created. 
Domain:  None  specified 

Purpose:  Allows  history  capture  of  an  establishment  table  for  a  unit. 
Entity;  EJTABLE 

Source  of  data  requirement:  CMDVT-AF 
Source  of  raw  data  for  database:  rM)VT-AF 


Data  Attribute  Name:  DATE_L_AMD  Format:  dd/mm/yy 

Full  Name;  Date  Establishment  Line  Last  Amended 

Description;  The  date  that  the  establishment  line  was  last  amended. 

Domain;  None  specified 

Purpose;  Allows  recording  of  when  establishment  lines  are  amended  for 
amendment  lists. 

Entity:  ESTAUTH 

Source  of  data  requirement;  Investigator 
Source  of  raw  data  for  database:  EM)VT-AF 


Data  Attribute  Name:  D_PRICE_ER  Format :  dd/mm/yy 

Full  Name:  Date  Estimated  Replacement  Price  Updated 

Description:  The  date  when  the  estimated  replacement  price  was  last 

updated. 

Domain:  None  specified 

Purpose:  Allows  accuracy  of  the  PRICE_ER  field  to  be  validated. 
Entity:  VEH_ROLE 

Source  of  data  requirement:  DMOVT-AF  post  Beta  test. 

Source  of  raw  data  for  database:  DMOVT-AF  during  update. 

Data  Attribute  Name:  ESTAUTORMK  Format:  X(30) 

Full  Name:  Establishment  Authority  Remarks 

Description:  A  field  that  contains  remarks  that  pertain  to  the  reason 
for  a  particular  establishment  authority. 

Domain:  Nbne  specified 

Purpose:  Allows  recording  of  information  pertaining  to  the 
establishment  of  a  vehicle. 

Entity:  ESTAUTH 

Source  of  data  requirement:  DMOVT-AF 

Source  of  raw  data  for  database:  Current  Establishment  Records 
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Data  Attribute  Name:  EST_DATE  Format:  dd/mm/yy 
Full  Name:  Establishment  Date 

Description;  Hie  calendar  date  when  this  establishment  authority  s-jas 
last  amended. 

Domain:  None  specified 

Purpose ;  Allows  capture  of  update  transactions  and  could  provide  a 
catalyst  for  review. 

Entity:  ESTAUTH 

Source  of  data  requirement:  rM)VT-AF 
Source  of  raw  data  for  database;  IM3VT-AF 


Data  Attribute  Name:  EST_LINE  Format;  9(3) 

Full  Name:  Establishment  Line 

Description:  A  number  that  uniquely  identifies  an  establishment 
authority  within  an  establishment  table  for  an 
establishment  type. 

Domain:  1  to  999 

Purpose:  To  allow  separate  access  to  lines  on  an  establishment  that 
relate  to  a  vehicle. 

Entity:  ESTAUTH 

Source  of  data  requirement:  DMOVT-AF 
Source  of  raw  data  for  database;  IM5VT-AF 


Data  Attribute  Name;  EST_LINE  Format ;  9(3) 

Full  Name:  Establishment  Line  Identifier 

Description;  A  number  that  uniquely  identifies  an  establishment 
authority  within  an  establishment  table  for  an 
establishment  type. 

Domain:  None  specified 

Purpose:  Part  of  the  l<:ey  to  ESTAUTH  and  assists  in  unique 
identification  of  an  EVR  offset. 

Entity:  E\/R_OFF 

Source  of  data  requirement;  CMDVT-AF 
Source  of  rav/  data  for  database;  EMOVT-AF 


Data  Attribute  Name:  EST_TYPE  Format :  X(2) 

Full  Name:  Establishment  Type 

Description:  Denotes  the  type  of  establishment  authority. 

Domain:  None  specified 

Purpose:  Part  of  unique  identifier  of  an  establishment  authority. 
Entity;  ESTAUTH 

Source  of  data  requirement;  DMOVT-AF 
Source  of  raw  data  for  database;  DMOVT-AF 


Data  Attribute  Name:  ESTJTYPE  Format:  X(2) 

Full  Name:  Establishment  Type 

Description:  Denotes  the  type  of  establishment  authority. 
Domain:  None  specified 

Purpose;  Part  of  the  unique  identifier  of  an  EVR  offset. 
Ent i ty :  EVR_OFF 

Source  of  data  requirement:  £MDVT-AF 
Source  of  raw  data  for  database:  DMOVT-AF 


Data  Attribute  Name:  ESTJTYPE  Format:  X(2) 

Full  Name;  Establishment  Type 

Description:  Denotes  the  type  of  establishment  authority. 

Donain:  UE,TE,DS,OE 

Purpose; 

Ent i ty :  ESTJTYPE 

Source  of  data  requirement:  DMOVT-AF 
Source  of  raw  data  for  database;  DMOVT-AF 


Data  Attribute  Name:  ESTJTYPE_D  Format:  X(20) 
Full  Name;  Establishment  Type  Description. 
Description:  Describes  the  type  of  establishment. 
Danain:  None  specified 
Purpose; 

Entity:  EST_TYPE 

Source  of  data  requiranent:  DI(AF)AAP3631.001 
Source  of  raw  data  for  database:  DMOVT-AF 


Data  Attribute  Name;  EUNAME  Format:  X(10) 

Full  Name:  Establishment  Unit  Name 

Description:  The  short  name  given  to  an  establishment  unit  to  allow 
identification. 

Domain:  None  specified 

Purpose:  Allows  easy  identification  of  an  establishment  unit. 
Entity:  E_UNIT 

Source  of  data  requirement;  DMOVT-AF 
Source  of  raw  data  for  database;  IM3VT-AF 


Data  Attribute  Name.-  EU_ADDRESS  Format:  X(50) 

Full  Name:  Establishment  Unit  Address 

Description:  The  postal  address  of  a  unit  responsible  for  local  MT 
establishment  management. 

Domain:  None  specified 

Purpose:  Provides  the  location  of  the  unit  responsible  for 
managing  MT  elements. 

Entity:  E_UNIT 

Source  of  data  requirement:  DMOVT-AF 

Source  of  raw  data  for  database:  DI(AF)AAP  5131.001 
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Data  Attribute  Name:  EU_FILEREF  Format:  x(40) 

Full  Name:  Establishment  Unit  File  Reference 

Description:  The  file  reference  quoted  on  the  BVR,  used  by  the 

establishment  unit  for  cross-reference. 

Domain:  Ndne  specified 

Purpose-  Allans  recording  of  unit  cross-references. 

Entity:  EVR 

Source  of  data  requirement:  EVR 

Source  of  raw  data  for  database:  IMDVT-AF,RMS,EVR 


Data  Attribute  Name:  EU_NAME  Format:  X(10) 

Full  Name:  Establishment  Unit  Name 

Description:  The  abbreviated  title  of  the  unit  supplying  local  transport 
assets  and  transport  management  seirvices. 

Domain:  None  specified 

Purpose:  Identifies  the  local  manager  of  vehicle  assets. 

Entity:  E_TABLE 

Source  of  data  requirement:  CMOVT-AF 
Source  of  raw  data  for  database:  EM)VT-AF 


Data  Attribute  Name:  EVR_DATE  Format :  dd/mm/yy 
Full  Name:  Date  EVR  Submitted 

Description:  The  date  an  EVR  was  submitted  to  a  host  unit  for 
processing. 

Dgnain:  Nbne  specified 

Purpose:  Allows  tracking  of  EVRs  and  identification. 

Entity:  EVR 

Source  of  data  requirement;  DI(AF)AAP363l.00l 
Source  of  rav/  data  for  database:  RMS/DMOVT-AF 


Data  Attribute  Name:  EVR_OFFRMK  Format:  X(50) 

Full  Name:  EVR  Offset  Remarks 

Description:  Remarks  made  against  a  particular  offset  on  an  EVR. 
Domain:  None  specified 

Purpose:  Allows  capture  of  ccxnments  at  the  individual  offset  level  of 
an  EVR. 

Entity:  EVR_OFF 

Source  of  data  requirement;  IMDVT-AF 
Source  of  raw  data  for  database;  [M}VT-AF 


Data  Attribute  Name:  EVR_RMKS  Format :  X(200) 

Full  Name:  Establishment  Variation  Request  Remarks 

Description:  Remarks  made  concerning  the  entire  establishment  request. 

Domain:  None  specified 

Purpose:  Allov/s  remarks  concerning  the  entire  EVR  to  be  recorded. 

Ent i ty :  EVR 

Source  of  data  requirement:  DI(AF)AAP363 1.001  15  A 
Source  of  raw  data  for  database:  IM3VT-AF 
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Data  Attribute  Name:  EVRJTASK  Format:  X(lOO) 

Full  Name:  Nature  of  Tasking  for  EVR  Variation 

Description:  Denotes  the  nature  of  the  task  that  relates  to  the 

requirement  for  EVR  variation. 

Domain:  None  specified 

Purpose:  Allows  capture  of  information  about  each  variation. 
Entity:  EVR_VAR 

Source  of  data  requirement:  DI(AF)AAP3631.001  15  A 
Source  of  raw  data  for  database: 


Data  Attribute  Name:  EVR_VARQTY  Format:  S9(3) 

Full  Name:  EVR  Variation  Quantity 

Description:  The  quantity  of  the  SVI  requiring  variation. 

Domain:  None  specified 

Purpose ;  Allows  the  number  of  vehicles  in  an  EVR  to  be  quantified. 
Entity:  EVR_VAR 

Source  of  data  requirement:  DI(AF)AAP3631.001  15  A 
Source  of  raw  data  for  database:  custcmer  unit 


Data  Attribute  Name:  E_AMEND_NO  Format :  9(3) 

Full  Name:  Establishment  Table  Amendment  Number 

Description:  Denotes  the  current  version  of  an  establishment  table  for  a 
unit. 

Domain:  None  specified 

Purpose:  Allows  current  and  previous  establishment  tables  to  be 
identified. 

Entity:  EJTABLE 

Source  of  data  requirement:  DMOVT-AF 
Source  of  raw  data  for  database:  WOVT-AF 


Data  Attribute  Name:  E_FILE_REF  Format :  X(4) 

Full  Name:  Establishment  Table  File  Reference 
Description:  Identifies  the  establishment  table  for  a  unit 
established  to  hold  and  manage  OT  assets. 

Domain:  None  specified 

Purpose :  Allows  grouping  of  establ i .shment  authorities  together  for 
management  purposes. 

Entity:  E_TABLE 

Source  of  data  requirement;  DMOVT-AF 
Source  of  raw  data  for  dataiJase :  DMOVT-AF 


Data  Attribute  Name:  E_FILE_REF  Format :  X(4) 

Full  Name:  Establishment  Table  File  Reference 
Description:  Identifies  the  establishment  table  for  a  unit 
established  to  hold  and  manage  OT  assets. 

Dcanain:  None  specified 

Purpose :  Assists  to  uniquely  identify  an  EVR  Offset. 
Entity:  EVR_OFF 

Source  of  data  requirement:  DMOVT-AF 
Source  of  raw  data  for database :  EMDVT-AF 


Data  Attribute  Name:  E_FILE_REF  Format :  X(4) 

Full  Name:  Establishment  Table  File  Reference 
Description:  Identifies  the  establishment  table  for  a  unit 
established  to  hold  and  manage  WT  assets. 

Domain:  Nbne  specified 

Purpose:  Denotes  the  establishment  table  that  the  EVR  seeks  to  amend. 
Ent i ty :  EVR 

Source  of  data  requirement:  DI(AF)AAP3631.001  15 
Source  of  raw  data  for  database:  EMDVT-AF  (EVR) 


Data  Attribute  Name:  E_FILE_REF  Format :  X(4) 

Full  Name:  Establishment  Table  File  Reference 
Description:  Identifies  the  establishment  table  for  a  unit 
established  to  hold  and  manage  NfT  assets. 

Domain:  Nbne  specified 
Purpose: 

Entity:  ESTAUTH 

Source  of  data  requirement:  DMOVT-AF 
Source  of  raw  data  for  database:  Dl^KDVT-AF 


Data  Attribute  Name:  E_UNIT_,EXT  Format :  9(5) 

Full  Name:  Establishment  Unit  Telephone  Contact  Extension 
Description:  The  Base  telephone  extension  for  the  position 
responsible  for  local  MT  establishment  management. 

Domain:  None  specified 

Purpose :  AlloV'/s  recording  of  the  contact  telephone  extension  for  each 
Establishment  Unit. 

Entity:  E_UNIT 

^  rce  of  data  requirement:  DMOVT-AF 
Source  of  rav/  data  for  database:  D^DVT-AF 
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Data  Attribute  Name:  E_UNIT_ID  Format:  X{5) 

Full  Name;  Establishment  Unit  Identifier 

Description:  An  abbreviation  allocated  to  a  unit  that  is  locally 
responsible  for  MT  establishment  management. 

Dcmain:  None  specified 

Purpose:  Uniquely  identifies  a  unit  where  an  establishment  is 
al located. 

Entity;  E_UNIT 

Source  of  data  requirement;  DI(AF)AAP3631.00i  Chapter  15 
Source  of  raw  data  for  database:  EMDVT-AF 


Data  Attribute  Name:  E_UNIT_ID  Format:  X(5) 

Full  Name:  Establishment  Unit  Identifier 

Description:  An  abbreviation  allocated  to  a  unit  that  is  locally 
responsible  for  ITT  establishment  management. 

Dgnain:  None  specified 

Purpose:  Denotes  the  establishment  unit  or  R1>1S  v;here  an  EVR  was 
initially  processed. 

Entity:  EVR 

Source  of  data  requirement:  DI(AF)AAP  3631.001  Chapter  15 
Source  of  raw  data  for  database:  CMOVT-AF 


Data  Attribute  Name;  E_UNIT_ID  Format;  X(5) 

Full  Name;  Establishment  Unit  Identifier 

Description;  An  abbreviation  allocated  to  a  unit  that  is  locally 
responsible  for  ITT  establishment  management. 

Domain:  None  specified 

Purpose;  Provides  a  means  of  grouping  together  establishments  for 
management  purposes. 

Entity;  E_TABLE 

Source  of  data  requirement;  EMDVT-AF 
Source  of  raw  data  for  database;  DMOVT-AF 


Data  Attribute  Name:  E_WEF_DATE  Format:  dd/mm/yy 
Full  Name:  Establishment  Table  With  Effect  Date 

Description:  The  calendar  date  fr<xn  viiich  the  current  amendment  of  the 
establishment  table  will  take  effect. 

Domain:  None  specified 

Purpose;  Allcws  grouping  of  establishment  authorities  together  for 
management  purposes. 

Entity:  E_TABLE 

Source  of  data  requirement;  DMOVT-AF 
Source  of  raw  data  for  database:  DMOVT-AF 
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Data  Attribute  Name:  F7\D  Format :  9(1) 

Full  Naiiie:  Force  Activity  Designator 

Description:  The  Force  Activity  Designator  of  the  unit  that 
requires  transport  services  or  assets. 

Domain:  None  specified 

Purpose:  Use  to  determine  priority  of  satisfaction  of  requests  for 
transport  support. 

Entity:  CUSTUNIT 

Source  of  data  requirement:  DMOVT-AF 

Source  of  raw  data  for  database:  DI(G)SUP  16-1 


Data  Attribute  Name:  I1H_VENUE  Format:  X(4) 

Full  Name:  Intermediate  Level  Maintenance  Venue 

Description:  Denotes  ^^Alere  intermediate  level  maintenance  is  to  occur. 
Domain:  RAAF,  COOT 

Purpose :  Allows  management  of  maintenance  of  vehicle  role 
categories. 

Entity:  VEH_ROLE 

Source  of  data  requirement:  DI(AF)AAP7070.014  paragraph  109  ALl 
Source  of  raw  data  for  database:  DI(AF)AAP7070.014  paragraph  109  ALl, 
DMP 


Data  Attribute  Name:  LASTREVIEW  Format:  dd/mm/yy 
Full  Name:  Last  Review  Date 

Description:  The  calendar  date  when  the  establishment  authority  was  last 
reviewed. 

Domain:  Nbne  specified 

Purpose:  Allows  recording  of  the  dates  when  EMDVT-AF  last  reviewed  the 
establ i shment . 

Entity:  ESTAUm 

Source  of  data  requirement:  DMOVT-AF 
Source  of  raw  data  for  database:  DMOVT-AF 


Data  Attribute  Name:  LICjCODE  Format :  X(2) 

Full  Name:  Licence  Code 

Description:  The  code  used  to  distinguish  groups  of  vehicles  for  driver 
licencing  purposes. 

Domain:  None  specified 

Purpose:  Allows  management  of  manpower  and  driver  licencing 
considerations. 

Entity:  VEH_R0LE 

Source  of  data  requirement:  DI(AF)3631.00l  Chapter  7 
Source  of  rav;  data  for  database:  DMOVT-AF 
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Data  Attribute  Name;  LOTKM  Format:  9(6) 

Full  Name:  Life  of  Type  Kilaneters 

Description:  The  number  of  kilometers  at  v^ich  a  vehicle  type  is  deemed 
ready  for  disposal. 

Dcm>a-r.  None  specified 

Purpose:  Used  for  the  determination  of  disposal  and  establishment 
authority  decisions. 

Entity:  VEH_ROLE 

Sov  ce  of  data  rec?uirement :  EMOVT-AF 

Source  of  raw  data  for  database:  DI(AF)AAP3631.001  Chapter  15 


Data  Attribute  Name:  LOTYEARS  Format :  9(2) 

Full  Name:  Life  of  Type  -  Years 

Description:  The  statutory  age  of  a  vehicle  type  v;hen  ready  for 
disposal . 

Domain:  None  specified 

Purpose:  Used  to  determine  the  disposal  dates  for  individual  vehicles. 
Entity:  VEH_ROLE 

Source  of  data  requirement:  EMOVT-AF 

Source  of  rav;  data  for  database:  DI(AF) 3631. 001  Chapter  15 


Data  Attribute  Name:  L_W£IF_DATE  Format:  dd/mm/yy 
Full  Name:  Establishment  Authority  Line  With  Effect  Date 
Description:  The  date  from  which  an  Establishment  Authority  Line  take 
effect. 

Domain:  None  specified 

Purpose:  Allo^/s  specification  of  establi.shments  in  advance  of 
requirements. 

Entity:  ESTAUTH 

Source  of  data  requirement:  I^OVT-AF 
Source  of  rav/  data  for  database:  DMOVT-AF 


Data  Attribute  Name:  MAX_CARG0  Format :  9(5) 

Full  Name:  Maximum  Cargo 

Description:  The  maximum  weight  expressed  in  kilograms  that  may  be 
carried  as  cargo  for  this  role  code. 

Dgnain:  None  specified 

Purpose:  Allows  vetting  of  EVR  and  other  requirements  for  a 
requirement  to  carry  cargo. 

Entity:  VEH_R0LE 

Source  of  data  requirement:  DI(AF)AAP363l.00l  Chapter  15 
Source  of  raw  data  for  database:  DI(AF)AAP363l .001  Chapter  15 
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Data  Attribute  Name:  MAX_LITRES  Format:  9(9) 

Full  Name:  Maximijm  Litres  Bulk  Liquid  Cargo 

Description:  The  maximum  allowable  amount  of  bulk  liquid  cargo  that  may 
be  carried  by  the  role  code. 

Domain:  None  specified 

Purpose;  Allows  determination  of  requirements  that  involve  the  need  to 
carry  bulk  liquids 
Eaititv:  VEH_ROLB 

Source  of  data  requirement:  DI{AF)AAP3631.001  Chapter  15 
Source  of  raw  data  for  database:  DI(AF)AAP3631.00l  Chapter  15 


Data  ^<~tribute  Name:  MAX_PAX  Format :  9(2) 

Full  Name:  Maximum  Passengers 

Description:  The  maximum  number  of  passengers  allowed  to  be 
transported  by  the  vehicle  role  code. 

'Domain:  None  specified 

Purpose:  Allov'/s  accurate  assessments  of  EVR  sutmission  and  other 
requirements. 

Entity:  VEH_ROLE 

Source  of  data  requirement:  DI (AF)AAP3631.001  Chapter  15 
Source  of  raw  data  for  database:  DI(AF)AAP363l.00l  Chapter  15 


Data  Attribute  Name;  MOBCAT  Format;  9(1) 

Full  Name;  Mobility  Category 

Description;  Denotes  the  mobility  capabilities  of  a  vehicle  role. 

Dcmain;  None  specified 

Purpose: 

Entity:  VEH_ROLE 

Source  of  data  requirement:  DI(AF)AAP363l.00l  15 
Source  of  raw  data  for  database;  DI40VT-AF 


Data  Attribute  Name:  MOBCAT  Format;  9(1) 

Full  Name;  Mobility  Category 

Description:  Describes  the  mobility  capabilities  of  a  vehicle  role. 
Domain:  1  TO  4  -SEE  ANNEX  C  Chapter  15  DI(AF)  AAP  3635.001 
Purpose: 

Entity;  MOBILITY 

Source  of  data  requirement:  IM)VT-AF 

Source  of  raw  data  for  database;  DI(AF)AAP3631.00l  Chapter  15  Annex  C 


Data  Attribute  Name:  M0BCAT_DES  Format :  X(150) 

Full  Name:  Mobility  Category  Description 

Description:  Narrative  describing  the  mobility  characteristics  of 
a  vehicle  type. 

Domain:  I'lone  .specified 
Purpose: 

Entity:  MOBILITY 

Source  of  data  requirement:  DI (AF)AAP363l .001  15  c 
Source  of  raw  data  for  database :  D^'1DVT-AF 
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Format :  9(13) 


Data  Attribute  Name:  NSN 
Full  Name:  NATO  Stock  Number 
Description;  Uniquely  identifies  each  item  of  supply. 
Domain:  None  specified 
Purpose: 

Entity:  VEH_ROLE 

Source  of  data  requirement:  CMDVT-AF 
Source  of  raw  data  for  database:  SG3 


Data  Attribute  Name:  PRICE_ER  Format:  9(6) 

Full  Name:  Estimated  Replacement  Price 

Description:  The  estimated  dollar  replacement  cost  for  a  particular 
vehicle  type. 

Domain;  None  specified 
Purpose:  Budgetary  projections. 

Entity:  VEH_ROLE 

Source  of  data  requirement:  DtfOVT-AF 
Source  of  rav/  data  for  database :  SG3 


Data  Attribute  Name:  QTYEST  Format:  9(3) 

Full  Name;  Establishment  -  Quantity 

Description;  Denotes  the  number  of  the  vehicle  type  established 
against  an  Establishment  Authority. 

Domain;  None  specified 

Purpose;  Denotes  the  quantity  of  a  vehicle  type  against  an 
establishment  type. 

Entity:  ESTAUTO 

Source  of  data  requirement:  CMOVT-AF 
Source  of  raw  data  for  database:  K-K)VT-AF 


Data  Attribute  Name;  QTY_0FFSE7r  Format;  s9(3) 

Full  Name;  Role  Code  Quantity  Offset 

Description:  The  quantity  of  the  role  code,  identified  on  a  current 
establishment  authority  that  is  identified  as  an  offset  on  a  EVR. 
Domain:  None  specified 

Purpose:  Allows  the  number  of  vehicles  to  be  specified  in  an  EVR 
offset. 

Entity;  EVR_OFF 

Source  of  data  requirement:  DI(AF)AAP3631.001  Chapter  15 
Source  of  raw  data  for  database:  EVR 
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Format;  X(3) 


Data  Attribute  Name:  RADIO 
Full  Name:  Radio  Required 
Description;  Denotes  if  a  radio  is  required  as  part  of  the  role  code 
configuration. 

Domain:  FFR 

Purpose:  Allcws  identification  of  role  codes  configured  for 
radios. 

Entity:  VEH_ROLE 

Source  of  data  requirement;  DI(AF)AAP363i.00l  Chapter  15 
Source  of  raw  data  for  database;  DI(AF)AAP363l.00l  Chapter  15 


Data  Attribute  Name:  ROLBjCODE  Format :  X(3) 

Full  Name:  Surface  Vehicle  Role  Code 

Description:  Uniquely  identifies  each  generic  vehicle  role  with  a  three 
letter  code,  which  are  the  first  three  letters 
of  an  SVI. 

Domain;  Alphas  only. 

Purpose:  Allows  unique  identification  of  generic  vehicle  types. 

Entity;  VEH_ROLE 

Source  of  data  requirement:  DI(AF)AAP363i.00i 
Source  of  raw  data  for  database;  AEENG5 


Data  Attribute  Name:  ROLEjDODE  Format ;  X(3) 

Full  Name;  Surface  vehicle  Role  Code 

Description;  Uniquely  identifies  each  generic  vehicle  role  with  a  three 
letter  code,  vAiich  are  the  first  three  letters 
of  an  SVI. 

Domain:  None  specified 

Purpose:  Assists  in  uniquely  identifying  an  EVR  offset. 

Ent i ty :  EVR_OFF 

Source  of  data  requirement;  DMOVT-AF 
Source  of  raw  data  for  database;  DMOVT-AF 


Data  Attribute  Name;  ROLEjCODE  Format:  X(3) 

Full  Name;  Surface  Vehicle  Role  Code 

Description:  Uniquely  identifies  each  generic  vehicle  role  V7ith  a  three 
letter  code,  which  are  the  first  three  letters 
of  an  SVI. 

Domain:  None  specified 

Purpose:  Allows  back-reference  to  the  EVR  Variation  that  originally 
established  line. 

Entity:  ESTAUm 

Source  of  data  requirement:  EMDVT-AF 
Source  of  raw  data  for  database:  D^DVT-AF 
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Data  Attribute  Name:  ROLE_CODE  Format :  X(3) 

Full  Name:  Surface  Vehicle  Role  Code 

Description:  Uniquely  identifies  each  generic  vehicle  role  with  a  three 
letter  code,  which  are  the  first  three  letter  of  an  SVI. 

Domain:  None  specified 

Purpose:  Denotes  the  vehicle  type  established  against  that 
establishment. 

Entity:  ESTAUTH 

Source  of  data  requirement:  Establishment  Tables 
Source  of  raw  data  for  database:  IM)VT-AF 


Data  Attribute  Name:  ROLEjCXDDE  Format:  X(3) 

Rail  Name:  Surface  Vehicle  Role  Code 

Description:  Uniquely  identifies  each  generic  vehicle  role  v/ith  a  three 
letter  code,  vrfiich  are  the  first  three  letters 
of  an  SVI. 

Domain:  None  specified 

Purpose:  Uniquely  identifies  an  BVR  variation  and  relates  it  to  a 
specific  SVI. 

Entity:  EVR_VAR 

Source  of  data  requirement:  DI(AF)AAP3631.00l  15  A 
Source  of  raw  data  for  database:  RMS/IM)VT-AF 


Data  Attribute  Name:  ROLE_DESC  Format:  X(50) 

Full  Nazne;  Surface  Vehicle  Role  Code  Description 
Description:  Describes  each  surface  vehicle  role  code. 
Dcxnain:  None  specified 

Purpose:  Allows  capture  of  descriptor  information. 
Entity:  VEH_ROLE 

Source  of  data  requirement:  EWOVT-AF 

Source  of  raw  data  for  database:  DI{AF)AAP  7010.014 


Data  Attribute  Name:  R_ANNOTATE  Format:  X(l) 

Full  Name:  Role  Annotation 

Description:  Describes  the  special  criteria  for  establishment  of  a 
vehicle  type  or  role. 

Domain:  None  specified 
Purpose: 

Entity:  VEH_R0LB 

Source  of  data  requirement:  CMOVT-AF 
Source  of  raw  data  for  database:  DMOVT-AF 
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Data  Attribute  Name:  R_ANNOTATE  Format :  X(l) 

E^ll  Name;  Role  Annotation 

Description:  Describes  the  special  criteria  for  establishment  of  a 
vehicle  role  or  type. 

Domain:  None  specified 

Purpose:  Allows  special  information  to  be  represented  against  certain 
vehicle  roles. 

Entity:  R_ANNOT 

Source  of  data  requirement:  DI(AF)AAP  3631.001  Chapter  15 
Source  of  raw  data  for  database;  DI(AF)AAP  3631.001 


Data  Attribute  Name:  R_ANN0T_D  Format :  X{120) 

Full  Name:  Role  Annotation  Description 

Description:  Describes  an  annotation  code  concerning  the  special 
criteria  required  for  establishment  of  a  vehicle  type  or  role. 
Dcanain:  None  specified 

Purpose:  Allows  description  of  a  special  vehicle  role 
characteristics. 

Entity:  R_ANN0T 

Source  of  data  requirement:  DI(AF)AAP3631.00l  Chapter  15  Annex  C 
Source  of  rav;  data  for  database:  DI(AF)AAP3631.001 


Data  Attribute  Name:  SELFDEP  Format;  X(2) 

Full  Name;  Self  Deployment  Code 

Description;  Describes  the  restrictions  regarding  deployment  of  a 
vehicle  type. 

Domain:  See  ANNEX  C  to  Chapter  15  of  DI(AF)AAP3635.001 
Purpose; 

Entity:  DEPLOY 

Source  of  data  requirement;  Dl(AF)AAP363l.00l  15  C 
Source  of  raw  data  for  database:  DMOVT-AF 


Data  Attribute  Name:  SELFDEP  Format :  X(2) 

Full  Name:  Self  Deployment  Code 

Description:  Describes  the  restrictions  regarding  deployment  of  a 
vehicle  type. 

Dgnain:  None  specified 
Purpose; 

Entity;  VEH_R0LE 

Source  of  data  requirement:  DI(AF) 3631. 001  15 
Soijrce  of  raw  data  for  database;  EM3VT-AF 
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Data  Attribute  Name;  SELFDEP_D  Format:  X{145) 

Full  Name:  Self  Deployment  Code  Description 

Description:  Description  of  a  code  that  describes  the  ability  of  a 
vehicle  to  self-deploy. 

Domain:  None  specified 
Purpose: 

Entity:  DEPLOY 

Source  of  data  requiranent:  DI(AF)AAP3631.001  15  A 
Source  of  raw  data  for  database:  DI(AF)AAP3631.001 


Data  Attribute  Name:  STDISN_REQ  Format:  X(3) 

Full  Name:  Standardisation  Required 

Description:  Denotes  the  requirement  to  standardise  the  procurement  in 
the  role  code. 

Dcmain:  None  specified 

Purpose:  To  meet  supply  or  engineering  support  requirements. 

Entity:  VEH_ROLE 

Source  of  data  requirement:  DI(AF)AAP7070.014  paragraph  114  ALl 
Source  of  raw  data  for  database:  DI(AF)AAP7070.014  Chapter  4 


Data  Attribute  Name:  STDjCOLOUR  Format:  X(10) 

Full  Name:  Standard  Colour 

Description:  The  standard  colour  for  the  vehicle  role  category. 
Domain:  None  specified 

Purpose:  Allows  management  of  vehicle  colours  by  role  code. 
Entity:  VEH_ROLE 

Source  of  data  requirement:  DI(AF)AAP7070.014  paragraph  112  ALl 
Source  of  raw  data  for  database:  DI{AF)AAP7070.014  Chapter  4 


Data  Attribute  Name:  SUP_SOURCE  Format :  X(6) 

Full  Name:  Vehicle  Supply  Source  Category 

Description:  Denotes  the  majiagement  category  to  vAiich  a  particular 
vehicle  type  belongs. 

Domain:  CC»i,  CCM-CL,  NCOM 

Purpose:  Used  to  manage  acquisition  and  disposal  of  vehicles  by  role 
code. 

Entity:  VEH_ROLE 

Source  of  data  requirement:  DMOVT-AF 

Source  of  raw  data  for  database:  DI(AF)AAP7010.014 


Data  Attribute  Name:  SVjCAT  Format :  X(2) 

Full  Name:  Surface  Vehicle  Category 

Description:  Denotes  the  generic  grouping  of  roles. 

Domain:  None  specified 

Purpose:  Relates  a  vehicle  role  code  to  a  category. 

Entity:  VEH_ROLE 

Source  of  data  requirement:  DI(AF)AAP363l.00l  paragraph  104 
Source  of  raw  data  for  database:  DI (AF)AAP363l .001  Chapter  4 
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Data  Attribute  Name:  SV_CAT  Format:  X(2) 

Full  Name:  Surface  Vehicle  Category 

Description:  Denotes  a  generic  grouping  of  vehicle  roles. 

Domain:  None  specified 

Purpose:  Allows  grouping  of  vehicle  roles  for  management  purposes. 
Entity;  SVjCAT 

Source  of  data  recaiirement:  DI(AF)AAP7070.014  paragraph  104 
Source  of  raw  data  for  database:  DI(AF)AAP7070.014  Chapter  3 


Data  Attribute  Name:  SV_CAT_DES  Format :  X(45) 

Full  Name:  Surface  Vehicle  Category  Description 

Description:  Describes  a  generic  category  of  surface  vehicle  role. 

Danain:  None  specified 

Purpose:  Allows  description  of  a  surface  vehicle  category’. 

Entity:  SV_CAT 

Source  of  data  requirement:  DI(AF)AAP7070.014  Chapter  4 
Source  of  raw  data  for  database:  DI(AF)AAP7070.014  Chapter  4 


Data  Attribute  Name:  SYS_ENG  Format ;  X{4) 

Full  Name:  Systems  Engineer 

Description:  The  HQLC  systems  engineer  contact  point  for 
engineering  management  of  role  code. 

Danain:  None  specified 

Purpose:  Allows  differentiation  between  engineering  elements 
responsibilities  at  HQLC. 

Entity:  VEH_R0LE 

Source  of  data  requirement:  DI(AF 17070.014  paragraph  115  ALl 
Source  of  raw  data  for  database:  DI(AF) 7070. 014  Chapter  4 


Data  Attribute  Name:  UTIL_PRAM  Format :  9.9 
Full  Name:  Establishment  Utilisation  Parameter 
Description:  A  fraction  used  by  IM3VT-AF  in  the  calculation  of 
acceptable  vehicle  utilisation  for  establishment  locations. 

Domain:  None  specified 

Purpose :  Ailot-/s  flexibility  of  managanent  of  establishments  by  location 
factors . 

Entity:  E_TABLE 

Source  of  data  requirement:  IMDVT-AF 
Source  of  raw  data  for  database:  EMOVT-AF 
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Data  Ati-ribute  Name:  V_FILE_REF  Format:  X{40) 

Full  Name:  EVR  File  Reference 

Description:  The  file  reference  of  the  originator  of  an  EVR. 
Detain:  None  specified 

Purpose:  Used  to  assist  in  uniquely  identifying  separate  EVR 
submissions  frean  a  customer. 

Entity:  EVR 

Source  of  data  requirement:  EMDVT-AF  /DI(AF)AAP363i.00i  Chapter  15 
Source  of  raw  data  for  database:  RMS/EM)VT-AF 


Data  Attribute  Name:  V_FILE__REF  Format:  X(4) 

Full  Name:  EVR  File  Reference 

Description:  The  file  reference  of  the  originator  of  an  EVR. 
Dcanain:  a(2)9(2) 

Purpose : 

Entity:  ESTAUTH 

Source  of  data  requirement:  DMOVT-AF 
Source  of  raw  data  for  database:  DNK)VT-AF 


Data  Attribute  Name:  V_FILE_REF  Format :  X(40) 

Full  Name;  EVR  File  Reference 

Description:  The  file  reference  of  the  originator  of  an  EVR. 
Dexnain:  None  specified 

Purpose:  Links  an  EVR  line  to  its  parent  EVR. 

Entity:  EVR_VAR 

Source  of  data  recaiirement :  DM0VT-AF/Dl(AF)AAP363l.00i  chapter  15 
Source  of  raw  data  for  database:  DMOVT  AF 


Data  Attribute  Name:  V_FILE__EIEF  Format :  X{40) 

Full  Name:  EVR  File  Reference 

Description:  The  file  reference  of  the  originator  of  an  EVR. 
Domain:  None  specified 

Purpose:  Links  an  offset  to  its  parent  EVR. 

Ent i ty :  EVR_OFF 

Source  of  data  requirement:  EMDVT-AF 
Source  of  rav;  data  for  database:  DMOVT-AF 


Data  Attribute  Name:  V_OP_CLASS  Format:  X(4) 

Full  Name:  Vehicle  Operational  Classification 

Description:  A  vehicle's  operational  classification  as  defined  in  DI(AF) 
TECH  17-15. 

Domain:  OPTV,  NOTV 
Purpose: 

Entity:  VEH_ROLE 

Source  of  data  requirement:  EMOVT-AF 

Source  of  raw  data  for  database:  DI (AF)AAP7070.014  Chapter  4 
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Data  Attribute  Name:  V_WEF_DATE  Format:  dd/mm/yy 
Full  Name:  EVR  With  Effect  Date 

Description:  The  date  that  an  EVR  variation  is  requested  to  be  effective 
from. 

Domain:  None  specified 

Purpose:  Allows  a  variation  request  to  be  processed  before  the 
requirement  must  be  filled 
Entity:  EVR_VAR 

Source  of  data  requirement:  DI(AF)AAP3631.001 
Source  of  raw  data  for  database:  customer  unit 


Data  Attribute  Name:  WINCH  Format :  X(3) 

Full  Name:  Winch  Required 

Description:  Denotes  if  a  v/inch  is  required  as  part  of  the 
configuration  of  a  vehicle  role  code. 

Doma i n :  None  specified 

Purpose:  Allows  selection  of  vehicle  roles  suitable  for  tasks  that 
require  a  v^inch. 

Entity:  VEH_ROLE 

Source  of  data  requirement:  DI (AF)AAP3631.001  Chapter  15 
Source  of  raw  data  for  database:  DI(AF)AAP363 1.001  Chapter  15 
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Appendix  C;  Entity  Attribute  List 


Introduction 

Ttie  entity  attribute  (EA)  list  is  used  to  in  conjunction  v/ith  the 
data  dictionary  and  entity  relationship  (ER)  diagram  to  represent  a 
model  of  the  database.  It  was  developed  and  maintained  on  Ashton  Tate's 
dBase  III  Plus™  and  the  report  produced  with  Relational  Report  Writer™. 

The  term  "Entity"  refers  to  the  grouping  of  two  or  more  data 
attributes  or  fields.  Attributes  are  listed  in  alphabetical  sequence 
except  for  primary  and  secondary  keys,  which  appear  first.  A  primary 
key  is  the  unique  identifier  of  a  record  in  that  entity.  Where  more 
than  one  attribute  is  listed  as  the  primary  key,  these  are  joined  or 
concatenated  together  to  form  the  primary  key.  Primary  keys  are 
represented  in  the  database  as  indexes  to  the  entities.  A  secondary  key 
is  the  primary  key  in  another  entity.  Its  inclusion  as  a  secondary  key 
in  an  entity  relates  it  to  a  specific  occurrence  (or  record)  of  the 
other  entity. 

Entity  Attribute  List  in  Entity  Sequence 

Ent i ty :  CUSTEL  --  Custaner  Element 
Attributes: 


Short  name  Status  l 

Format 

Long  name 

CUS'IEL_ID  Primary 

X(15) 

Custcmier 

Element 

Identifier 

CUSTU_SNAl''l  Foreign 

X(15) 

Custcmer 

Unit  Short  Name 

key  to  CUSTUNIT 

CUSTEL_NAI-1  Attribute 

X(30) 

Customer 

Element 

Name 

CUSTEL_PH  Attribute 

9(d: 

Customer 

Element 

Phone  Elxtension 

96 


Eintity:  CUSTUNIT  --  Custcxner  Unit 
Attributes: 


Short  name  Status 

Format 

Long  name 

aJSTU_SNAM  Primary 

X(5) 

Custcaner  Unit  Short  Name 

CUSTADDRES  Attribute 

X(50) 

Customer  Address 

CUSTROLE  Attribute 

X(30) 

Customer  Unit  Role 

CUSTU_TITL  Attribute 

X{30) 

Customer  Unit  Full  Title 

CUST_ID  Attribute 

X(5) 

Customer  Unit  Designator  Code 

FAL  Attribute 

9(1) 

Force  Activity  Designator 

Entity:  DEPLOY  --  Deployment 

Attributes: 

Short  name  Status 

Format 

Long  name 

SELFDEP  Primary 

X(2) 

Self  Deployment  Code 

SEIiFDEP_D  Attribute 

X(145) 

Self  Deployment  Code  Description 

Entity:  ESTAUTO  --  Establishment  Authority 

Attributes: 

Short  name  Status 

Format 

Long  name 

EST_LINE  Primary 

9(3) 

Establishment  Line 

ESTJTYPE  Primary 

X(2) 

Establishment  Type 

E_FILE_REF  Primary 

X(4) 

Establishment  Table  File  Reference 

ROLEjCODE  Pr i mary 

X(3) 

Surface  Vehicle  Role  Code 

CUSTEL_ID  Foreign  X(13) 

key  to  CUSTEL 

Customer  Element  Identifier 

ROLE_CODE  Fore i gn 

X(3) 

Surface  vehicle  Role  Code 

key  to  VEH_ROLE 
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EVR  File  Reference 


V_FILE_REF  Foreign  X ( 4 ) 
key  to  EVR 

DATB_L_AMD  Attribute  dd/mm/yy  Date  Establishment  Line  Last 

Amended 

ESTAUTORMK  Attribute  X(30)  Establishment  Authority  Renarks 

EST_DA’IE  Attribute  dd/nm/yy  Establishment  Date 

LASTREVIEW  Attribute  dd/mm/yy  Last  Review  Date 

L_WEF_DATE  Attribute  dd/mm/yy  Establishment  Authority  Line  With 

Effect  Date 

QTYEST  Attribute  9(3)  Establishment  -  Quantity 

Entity:  ESTJTYPE  --  Establishment  Type 
Attributes: 

Short  name  status  Format  Long  name 

EST_TYPE  Primary  X(2)  Establishment  Type 

EST_TYPE_D  Attribute  X(20)  Establishment  Type  Description. 

Entity:  EVR  —  Establishment  Variation  Request 
Attributes: 

Short  name  Status  Format  Long  name 

V_FILE_REF  Primary  X(40)  EVR  File  Reference 

CUSTU_SNAM  Foreign  X{15)  Custcmer  Unit  Short  Name 

key  to  CUSTONIT 

E_FILE_REF  Foreign  X(4)  Establishment  Table  File  Reference 

key  to  E_TABLE 

E_UNIT_ID  Foreign  X(5)  Establishment  Unit  Identifier 

key  to  E_UNIT 

CMD_REF  Attribute  X(40)  Command  File  Reference 

EU_F1LEREF  Attribute  X(40)  Establishment  Unit  File  Reference 
EVR_DATE  Attribute  dd/mm/yy  Date  EVR  Submitted 
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EVR_RMKS  Attribute  X(200)  Establishment  Variation  Request 

Remarks 

Entity:  EVRjOFF  --  Establishment  Variation  Request  Offset 
Attributes: 

Short  name  Status  Format  Long  name 

CUSTEL_ID  Primary  X(15)  Customer  Element  Identifier 

EST_LINE  Primary  9(3)  Establishment  Line  Identifier 

EST_TYPE  Primary  X(2)  Establishment  Type 

E_FILE_REF  Primary  X(4)  Establishment  Table  File  Reference 

ROLE_CODE  Primary  X(3)  Surface  Vehicle  Role  Code 

V_FILE_REF  Primary  X{40)  EVR  File  Reference 

CUSTEL_ID  Foreign  X(15)  Customer  Unit  Element  Identifier 

key  to  CUSTEL 

EVR_OFEI?MK  Attribute  X(50)  EVR  Offset  Remarks 

QTY_OFFSET  Attribute  s9(3)  Role  Code  Quantity  offset 

Entity:  EVR_VAR  --  Establishment  Variation  Request  Variation 
Attributes: 

Short  name  Status  Format  Long  name 

CUSTEL_ID  Primary  X(15)  Custc«ner  Unit  Element  Identifier 

ROLEjCODE  Primary  X(3)  Surface  Vehicle  Role  Code 

V_FILE_REF  Primary  X(40)  EVR  File  Reference 

EVRJTASK  Attribute  X(IOO)  Nature  of  Tasking  for  EVR  Variation 

EVR_VARQTY  Attribute  S9(3)  EVR  Variation  Quantity 

V_WEF_DATE  Attribute  dd/mm/yy  EVR  With  Effect  Date 
Entity:  EJTABLE  --  Establishment  Table 

Attributes: 

Short  name  Status  Format  Long  name 
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E_FILE_REF  Primary  X(4)  Establishment  Table  File  Reference 

E_UNIT_ID  Foreign  X(5)  Establishment  Unit  Identifier 

key  to  E_UNIT 

DATE_E_AMD  Attribute  dd/mm/yy  Date  Establishment  Table  Last 

Amended 

DATE_E_CBE  Attribute  dd/mm/yy  Date  Establishment  Table  Created 

EU_NAME  Attribute  X(10)  Establishment  Unit  Name 

E_AMEND_NO  Attribute  9(3)  Establishment  Table  Amendment 

Number 

E_WEF_DATE  Attribute  dd/mm/yy  Establishment  Table  With  Effect 

Date 

UTIL_PRAM  Attribute  9.9  Establishment  Utilisation  Parameter 

Entity;  E_UNIT  --  Establishment  Unit 
Attributes; 

Short  name  Status  Format  Long  name 

EUNAME  Primary  X(10)  Establishment  Unit  Name 

E_UNIT_ID  Primary  X(5)  Establishment  Unit  Identifier 

EU_ADDRESS  Attribute  X(50)  Establishment  Unit  Address 

E_UNIT_EXT  Attribute  9(5)  Establishment  Unit  Telephone 

Contact  Extension 

Entity;  MOBILITY  --  Mobility 
Attributes: 

Short  name  Status  Format  Long  name 

MOBCAT  Primary  9(1)  Mobility  Category 

MOBCAT_DES  Attribute  X(150)  Mobility  Category  Description 

Entity:  R  ANNOT  --  Role  Annotation 
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Attributes: 


short  name 

Status 

Format 

Long  name 

R_ANNCiTATE  Primary 

X(l) 

Role  Annotation 

R_ANN0T_D 

Attribute 

X(120) 

Role  Annotation  Description 

Entity:  SV  CAT  --  Surface  Vehicle  Category 

Attributes: 

Short  name 

Status 

Format 

Long  name 

SV_CAT 

Primary 

X(2) 

Surface  Vehicle  Category 

SV_CAT_DES 

Attribute 

X(45) 

Surface  Vehicle  Category 
Description 

Entity:  VEH  ROLE  --  Vehicle  Role 

Attributes: 

Short  name 

Status 

Format 

Long  name 

R0LE_C0DE 

Primary 

X(3) 

Surface  Vehicle  Role  Code 

MOBCAT 

Foreign  9(1) 

key  to  MOBILITY 

Mobility  Category 

R_ANNOTATE  Foreign  X{1) 

key  to  R_ANN0T 

Role  Annotation 

SELFDEP 

Foreign  X(2) 

key  to  DEPLOY 

Self  Deployment  Code 

SV_CAT 

Foreign  X(2) 

key  to  SV_CAT 

Surface  Vehicle  Category 

AIRPORTABI 

Attribute 

X(3) 

Airportability 

CAMOUFLAGE  Attribute 

X(3) 

Approval  for  Camouflage 

D_PRICE_ER  Attribute 

dd/mm/yy 

Date  Estimated  Replacement  Price 
Updated 

ILM_VENUE 

LIC_C0DE 

Attribute 

Attribute 

X(4) 

X(2) 

Intermediate  Level  Maintenance 
Venue 

Licence  Code 
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LOTKM  Attribute  9(6) 
LOTYEARS  Attribute  9(2) 
MAX_CARGO  Attribute  9(5) 
MAX_LITRES  Attribute  9(9) 
MAX_PAX  Attribute  9(2) 
NSN  Attribute  9(13) 

PRICE_ER  Attribute  9(6) 
RADIO  Attribute  X(3) 

ROLE_DESC  Attribute  X(50) 

STDISN_REQ  Attribute  X(3) 
STD_COLOUR  Attribute  X ( 10 ) 
SUP_S0URCE  Attribute  X(6) 
SYS_ENG  Attribute  X(4) 
V_0P_C1ASS  Attribute  X(4) 
WINCH  Attribute  X(3) 


102 


Appendix  D:  ESTAB  User  Manual 
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ESTAB  User  Manual 


Introduction 

The  Establishment  DBMS  application  (ESTAB)  automates  aspects  of 
the  EMOVT-AF  Motor  Transport  (MT)  establishment  management  functions. 

The  DBMS  uses  Nantucket  Corporation's  Clipper^**  computer  language  in 
conjunction  with  Aston-Tate  dBASE  III  Plus^**  compatible  databases  and 
indexes.  The  systan  allows  users  with  a  working  knowledge  of  the  RAAF 
MT  establishment  system  and  data  entry  processes  to  add,  edit,  delete, 
and  report  database  information.  The  application  requires  little 
knowledge  of  the  packages  used  to  create  the  system,  however  a  basic 
knowledge  of  database  concepts  would  assist  the  user  in  understanding 
and  using  the  system. 

The  ESTAB  User's  Manual  provides  a  reference  for  DBMS  operations. 
You  should  read  this  short  manual  in  its  entirety  before  attempting  to 
either  install  or  perform  tasks  with  ESTAB. 

Computer  Hardware  Requirements.  ESTAB  was  designed  to  run  on  IBM 
and  IBM  compatible  microcomputers  to  be  purchased  in  accordance  with 
DESINE  standards.  The  application  is  too  large  to  be  run  frcsn  a  5.25 
inch  drive  and  must  be  installed  on  the  hard  disk  of  the  microccmputer. 
Additionally,  you  will  require  640  k  of  random  access  memory  (RAM). 

Computer  Configuration  Requirements.  The  application  requires  the 
"config.sys"  file  to  contain  the  folloic/ing  statements: 
buffers  =  20 
files  =  20 
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The  existence  of  too  many  terminate  and  stay  resistant  (TSR)  programs 
will  reduce  the  availability  of  RAM  to  ESTAB.  If  ESTAB  states  "Not 
enough  memory"  you  will  need  to  disable  seme  or  all  of  the  TSRs  to 
execute  the  program.  This  should  not  normally  pose  a  problem. 

Installation 

Ttie  following  information  is  provided  to  supplement  the  on-screen 
instructions  provided  during  the  installation  of  ESTAB. 

An  installation  program  allows  you  to  easily  install  a  working 
copy  of  ESTAB  to  your  hard  disk.  You  should  have  one  5.25  inch  disk: 
ESTAB  1  available  for  this  task.  To  load  ESTAB  you  require  a  hard  disk 
with  2  megabytes  of  free  memory  on  the  "C"  drive. 

Installation  when  CTREE  is  Active.  "DTREE"  is  a  directory  program 
that  has  been  installed  on  your  micro-computer.  CTREE  must  be 
deactivated  or  bypassed  to  load  ESTAB.  If  DTREE  is  active,  select 
"QUIT"  in  CTREE  to  return  you  to  the  DOS  "C:>"  prompt. 

Previous  Versions  of  ESTAB.  If  you  are  running  a  previous  copy  of 
ESTAB  in  the  ESTAB. DEM  directory  on  your  C  drive,  you  will  need  to  run 
RID. BAT  contained  on  disk  l  to  erase  it.  If  you  have  files  in  that 
directory  that  you  wish  not  to  delete,  you  must  remove  them  to  another 
directory  before  running  RID. 

To  run  RID,  insert  disk  1  in  the  A  drive  and  type  "a:".  After  the 
"A:>"  appears  type  "RID"  and  press  <Enter>.  All  the  files  in  that 
directory  will  be  erased  and  the  directory  will  be  removed  from  the 
disk. 

Installing  ESTAB.  To  install  ESTAB,  type  "INSTALL"  at  the  "A:>" 
prompt  and  press  <Enter>.  The  install  program  will  copy  across  all  the 
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program,  database,  and  index  files  from  disk  1  that  make  up  ESTAB.  You 
are  new  ready  to  run  ESTAB. 

Getting  Started 

Itie  installation  program  will  leave  you  in  the  "C:\ESTAB.DEM" 
directory.  If  you  wish  to  start  ESTAB  from  outside  this  directory,  you 
should  include  that  directory  in  your  AUTOEXEC.BAT  path  statement.  For 
more  information  on  path  statements  consult  your  DOS  manual. 

DTREE  Bypass.  ESTAB  can  be  run  frexn  either  within  DTREE  or 
straight  from  the  DOS  prompt.  To  bypass  DTREE,  select  QUIT  in  DTREE  and 
you  will  be  returned  to  the  "C:>"  prompt.  Type  "CD  C:\ESTAB.DEM"  and 
press  <Enter>.  You  will  new  see  the  "C:\ESTAB. DEM>"  prompt  telling  you 
that  you  are  now  in  the  ESTAB. DEM  directory  on  the  C  drive. 

To  start  ESTAB  type  "ESTAB"  at  the  "C:\ESTAB.DEM"  prompt.  TTie  first 
thing  you  will  see  is  a  long  horizontal  box.  Figure  UM-l  is  the  main 
menu. 


Ue leone  to  the  NT  NIS  Establ ishnent  Nodule  Uersion  1.1 
developed  for  DNOVT-AF. 

Ple«se  select  fron  one  of  the  following  options  bg  either  selecting 
the  highlighted  letter  or  highlighting  the  choice  and  pressing  enter. 


Help  9«t«b«se  Naint  Xeports  Exit 


Figure  UM-l.  Main  menu 


Main  Menu.  The  main  menu  provides  four  possible  selections:  Help, 
Database  Maintenance,  Reports,  and  Exit.  The  Help  selection  v/i 1 1 
provide  basic  information  about  it  and  the  other  three  main  menu 
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selections.  Directions  to  assist  you  are  provided  on  each  of  the  menus 
and  the  fianctions. 

Pull-down  Menus.  Pull-down  menus,  such  as  depicted  in  Figure  UM- 
2,  have  been  installed  to  allow  you  perform  functions  and  to  trace  your 
path  back  to  higher  levels. 


=  Reports  — 
concerning  establishnents 

HT  Esiabliobnent  Table 
for  an  Estab I ishnent  Unit 

Consolidated  SuMnary  of 
all  KT  Establishnents 

MT  Establishments  for 
a  Customer  Unit 

NT  Establishnents  by 
a  Nobility  Code 

NT  Establishnents  by  a 
Self  Beploynent  Category 
■  —Esc  to  Exit== 


Figure  UM-2.  Pull-down  Menus 


There  are  two  ways  to  activate  a  selection: 

a.  highlight  the  option  by  using  the  cursor  or  arrow  keys  on  the 
keyboard,  or 

b.  press  the  highlighted  letter  of  the  selection  that  you  require. 

The  Help  Selection.  A  brief  explanation  of  functions  is  provided 
to  the  user  for  each  section.  The  Help  selection  from  the  main  menu 
provides  a  brief  summary  of  the  functions  of  each  section.  Comments  are 


109 


provided  on  each  menu  to  assist  you.  Menus  in  Delete  and  Report 
functions  provide  explanations  at  the  bottcm  left  corner  of  the  screen. 
These  explanations  change  with  each  option  highlighted.  For  more 
information  about  each  function  of  ESTAB  refer  to  the  later  sections  of 
this  manual . 

Quitting  an  Operation.  At  any  stage  you  want  to  abort  vrtiat  you 
are  doing  in  ESTAB  just  hit  the  escape  key  (<Esc>)  and  follow  the 
directions.  You  may  need  to  do  this  a  number  of  times  to  quit  lov/er 
menus  and  procedures. 

Database  Maintenance 

There  are  three  possible  selections  from  this  the  Database 
Maintenance  Menu  (Figure  UM-3) . 


Rdd  diU 

Edit  existing  daU 
Delete  Current  Data 
Esc  to  Exit  — 

Figure  UM-3.  Database  Maintenance  Menu 

ADD  allcws  you  to  add  additional  data  to  the  database  that  you  select  in 
the  next  menu.  EDIT  allows  you  to  make  any  necessary  changes  to 
information  contained  in  the  database  that  you  choose  on  the  next  menu. 
Delete  allov/s  you  to  delete  a  record  frcmi  the  database  that  you  choc  e 
from  the  next  menu  (Figure  UM-4). 
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Adding  Data.  ESTAB  allows  you  to  enter  a  great  deal  of 
information  about  vehicles  (role  codes),  establishments,  and  custcaners. 
See  Figure  UM-4  for  these  areas. 


Figure  UM-4.  Add  Menu 


The  programs  check  the  information  as  you  enter  it.  If  you  attempt  to 
enter  a  value  to  a  field  ESTAB  doesn't  know  from  its  tables,  it  will  ask 
you  if  you  wish  to  use  the  lookup  table.  If  you  can't  find  the  value 
that  you  wanted,  you  must  either: 

a)  enter  another  value  and  edit  it  later  with  the  edit  option  or, 

b)  exit  and  add  the  new  value  to  the  appropriate  database. 
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Uelcom  to  the 
Surf«ce  Uehicle  Category 
Md  Nodule 

Please  add  the  new  surface  category  or  fanily  details 
to  the  fields  below: 

Surface  Uehicle  Category  U 
Descriptiac  of  the  code 


Figure  UM-5.  Add  Screen 

Both  ADD  and  EDIT  options  will  allow  you  to  change  any  of  the 
values  in  the  highlighted  fields  on  the  screen  (Figure  UM-5).  When  you 
are  satisfied  press  the  control  and  W  keys  simultaneously  (<ctrl  w>)  or 
if  you  wish  to  exit  press  the  escape  key  (<Esc>).  You  may  be  again 
asked  to  choose  between  these  actions  depending  upon  when  you  decided  to 
stop  adding  or  editing  the  record.  If  you  proceeded  to  the  last 
highlighted  field  before  making  the  selection,  you  will  only  be  asked 
once. 

Sane  fields  are  too  long  to  fit  on  the  screen  all  at  once.  For 
these  (Mobility,  Self  Deployment,  and  Role  Annotation  descriptions),  the 
field  will  scroll  left  and  right.  To  get  to  the  first  letter  when  in 
this  field,  press  "HCME".  To  reach  the  last  letter,  press  "END". 

Locating  and  Editing  Data.  ESTAB  allows  you  to  identify  the 
record  you  want  to  edit  with  a  lookup  window  (Figure  UM-6).  This  lookup 
window  is  also  used  in  delete  and  scane  report  functions. 

As  with  the  ADD  procedures,  ESTAB  will  check  your  input  in 
important  fields.  If  your  value  doesn't  exist  you  will  be  queried  to 
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Please  select  fron  one  of  the  following: 
Role  Code  |  Description 


Unft  ftutQnoliile.  Statifiit  yag{n);fliT  Traffic  Control 

UflD  Truch/  IITC  Monitoring  Approach,  4x2 

UAE  Bus,  Carryall  (QD)  4x2 

UAL  Bus,  Aircrew  4x2 

UBB  Truck  Panel  Uan,  GP  25Bkg  4x2 

UBC  Tractor  Towing  Light 

UBD  Tractor  Aircraft  Towing,  Median 

UBC  Truck  Aircraft  Airconditioning 

UCA  Truck,  Carryall  (OD)  4x2 

UCC  Trailer  Cable  Laying 

UCD  Truck  Maintenance  Panel  Uan  4x2 

UDA  Truck,  Explosive  Qrdance  Disposal  4x4 

UBC  Forklift,  Explosive,  High  Mast  2.7t 

UE6  Trailer.  Articulated  AMS  (12M) 

UEC  Truck,  Aircraft  Loading/Unloading  (TALU),  4x2 


Use  Ti  to  select  press  return;  ESC  to  quit! 


Figure  UM-6.  Lookup  Window 


pick  a  current  value  or  have  another  attempt  at  entering  the  value.  To 
save,  press  <Ctrl  W>and  to  escape,  press  <Esc>. 

Deleting  Data.  ESTAB  allows  you  to  lookup  which  record  frcan  the 
entity  you  wish  to  delete.  This  table  will  appear  after  the  following 
screen  similar  to  Figure  UM-7.  If  at  any  stage  you  wish  to  quit  press 
<Esc>.  The  record  will  not  be  deleted. 

As  stated  in  the  introduction,  ESTAB  has  been  organised  to  ensure 
the  accuracy  and  validity  of  all  data  input  to  the  fields.  Data  is 
checked  on  input  and  editing  to  ensure  that  it  appears  in  related 
records  in  other  tables. 
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Delete  Uehicle  Role  Types 


Please  choose  fron  the  following: 
Return  to  min  Menu  Delete  records 


Figure  UM-7.  Delete  Screen 

A  word  of  warning  about  deleting.  Deleting  occurrences  of  lower  level 
records  such  as  a  "Vehicle  Role  Code”  will  effect  linked  information. 
You  should  delete  occurrences  of  records  containing  that 
information  in  related  tables  before  removing  the  source  of  that 
information.  For  example,  if  you  were  going  to  remove  Role  Code  "VAA", 
you  should  remove  all  reference  to  "VAA"  in  establishment  authorities 
beforehand  so  that  they  do  not  become  orphans  values. 

Reports.  ESTAB  allows  you  to  produce  reports  to  three  possible 
destinations:  printer,  display  (monitor),  or  file  as  shown  in 
Figure  UM-8. 

ESTAB  will  check  to  see  if  the  printer  is  ready  before  attempting 
to  write  your  report.  All  reports  are  currently  designed  for  an  EPSON 
compatible  printer.  If  you  elect  to  dump  the  report  to  a  file,  it  v/ill 
be  saved  in  ASCII  text.  Please  ensure  that  the  filename  used  is  legal 
in  DOS  (i.e.  8  letters  with  a  3  letter  extension,  e.g.  REPORT.TXT) 
otherv;i.se  an  error  will  occur.  You  may  also  include  a  path  (e.g. 

A; REPORT.TXT)  to  direct  your  report  to  another  disk  or  directory. 
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Report 

Unit  HT  Establishment  Table 

Please  choose  from  the  following: 
EKit 

Print  Report 
Display  Report 
Export  to  disk  file 


Figure  UM-8.  Typical  Report  Menu 

S«ne  specific  reports  also  use  lookups  to  identify  the  information 
you  require.  This  will  save  you  having  to  print  out  all  the  database 
information  in  the  report.  A  brief  description  of  the  reports  follov/s. 

Establishment  Reports 

These  reports  deal  with  information  about  the  MT  establishment. 
They  allow  the  MT  establishment  to  be  viewed  from  a  number  of  different 
perspectives.  Figure  UM-9  is  the  Establishment  Reports  Menu. 

MT  Establishment  Table  for  an  Establishment  Unit.  This  report 
v/ill  produce  a  listing  of  all  current  authorised  MT  Establishments  for  a 
particular  unit  responsible  for  holding  and  managing  an  establishment. 
The  particular  unit  required  must  be  selected  from  a  pick-list  displayed 
follov-zing  the  report  menu. 
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=*=  Keports  '  — 

concerning  establishiwnts 

MT  E8i«lli»bM0nt  T4ble 
for  an  EsioibiishMent  Unit 

Consol  idatsd  Sanmrg  of 
ill  NT  IsUMisbnents 

MT  Istablisbnents  for 
i  Cusiofter  Unit 

HT  Estiblishnents  by 
a  Mobility  Code 

HT  Establisbnents  by  a 
Self  BepIogoieRt  Category 
P-  -  —  Esc  to  Exit=  ■  - 

Figure  UM-9.  Establishment  Reports  Menu 

Consolidated  Summary  of  all  ^f^  Establishments.  A  consolidated 
list  of  all  vehicle  holdings  by  establishment  table,  establishment 
type, and  vehicle  role  can  be  provided  by  this  option.  This  could  be  a 
lengthy  report  and  vrould  be  best  run  during  standdown  periods  or  other 
times  when  the  computer  is  not  required. 

MT  Establishments  for  a  Custcmer  Unit.  This  report  will  list  all 
MT  authorisations  for  a  customer  unit  across  all  establishment  tables. 

MT  Establishments  by  Mobility  Code.  This  report  alloivs  listing  of 
all  current  establishments  to  be  selected  frcm  a  pick- list.  The 
report  allays  checking  the  validity  of  all  establishments  from  a 
mobility  perspective. 

ffT  Establishments  by  Self  Deployment  Category.  This  report  allotis 
listing  of  all  MT  establishments  for  all  vehicle  role  codes  that  have  a 
given  Self  Deployment  Category.  The  Self  Deployment  Category  must  be 
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selected  from  a  displayed  pick-list.  The  report  allov/s  checking  the 
validity  of  all  establishments  from  a  deployment  perspective. 

Policy  Reports 

These  reports  deal  with  policy  decided  by  DMOVT-AF  that  directly 
affects  MT  establishments.  Figure  UM-IO  is  the  Policy  Reports  Menu. 


h  Reports  ^  ■  -n 

concerning  policy 

Estdblislineni  and 
Repiacefteni  Criteria 

Role  Annotations 

Depioynent  Categories 

Mobility  Codes 

L:.:  vr  .Tr====£sC  tO  EHit=====M 
Figure  UM-lO.  Policy  Reports  Menu 

Establishment  and  Replacement  Criteria.  This  report  produces  a 
list  of  all  vehicle  role  codes  and  their  associated  establishment  and 
replacement  criteria.  The  format  of  this  report  is  the  same  as  the 
report  of  the  same  name  that  appears  in  Chapter  15  of  DI(AF)W\P3635.00i. 

Role  Annotations.  This  report  lists  ail  annotations  that  restrict 
the  employment  of  vehicles  against  NTT  establishments.  The  report  is 
formatted  as  Annex  A  to  the  Establishment  and  Replacement  Criteria 
Report  described  above. 

Deployment  categories.  The  Deployment  Categories  Report  lists  all 
current  Self  Deployment  Categories  in  the  format  of  Annex  B  to  the 
Establ isliment  and  Replacement  Criteria  Report. 
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^fobility  Codes.  The  Mobility  Codes  Report  lists  all  current 


mobility  codes  and  their  abbreviations  in  a  format  of  Annex  C  to  the 
Establishment  and  Replacement  Criteria  Report. 

Vehicle  Role  Code  Reports 

These  three  reports  provide  listings  of  the  current  vehicle  roles 
by  different  perspectives.  These  reports  allow  checking  of  controlled 
codes  allocated  against  all  vehicle  types.  Figure  UM-ll  illustrates  the 
Vehicle  Report  Menu. 


—  —  Reports 
listing  Uehicle  Roles  by: 

Mobility  Codes 

Role  Annotations 

Deploynent  Categories 

S— ■  -Esc  to  Exit--  ” 

Figure  UM-ll.  Vehicles  Report  Menu 

Mobility  Codes.  This  report  lists  all  vehicle  types  in  ascending 
role  code  sequence  grouped  by  each  mobility  classification. 

Role  Annotations.  This  report  lists  all  vehicle  types  is 
ascending  role  code  sequence  grouped  by  each  role  annotation 
classification. 

Deployment  Categories.  This  report  lists  all  vehicle  types  in 
ascending  role  code  sequence  grouped  by  their  ability  to  self  deploy  to 
remote  locations. 
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Tutorials 


Hie  follov7ing  represent  some  notes  of  guidance  for  the 
inexperienced  user  of  ESTAB.  The  tutorials  are  aimed  at  familiarising 
the  user  with  the  generic  functions  of  ESTAB. 

Creating  an  Establishment  Table 

Before  creating  a  new  Establishment  Table,  information  that  table 
will  refer  to  must  be  loaded.  If  the  Establishment  Unit  responsible  for 
managing  the  establishment  does  not  exist,  it  must  be  added  first. 

Should  you  attempt  to  add  an  Establishment  Table  when  these  details  do 
not  exist  you  will  need  to  exit  and  add  them  before  resuming  the 
creation  of  the  table.  The  following  paragraphs  provide  a  step-by-step 
approach  to  creating  a  new  table,  including  adding  Establishment  Unit 
details. 

Adding  an  Establishment  Unit.  To  add  an  Establ i shir.:^nt  Unit  from 
the  main  menu,  press  "DAH".  The  following  screen  will  appear  (Figure 
UM-12).  Fill  in  all  the  fields.  When  you  are  satisfied  with  your 
entries  and  wish  to  save,  press  <ctrl  W>.  If  you  wish  to  abort  the  add, 
press  <Esc>. 

Adding  an  Establishment  Table.  To  add  a  nev/  Establishment  Table, 
return  to  the  Add  menu  and  press  <b>.  You  will  see  the  following  screen 
(Figure  UM-13) . 

The  follov/ing  notes  may  assist  you.  Establishment  Table  reference 
is  a  code  four  letters  long  that  usually  begins  with  "VE" .  You  must 
enter  a  value  in  this  field. 
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Uelcone  to  the 
Estdbl ishnent  Unit 
m  Nodule 

Please  add  the  details  about  a  neu  unit  responsible  for  managing 
;RnOF  MT. 

;Uhat  is  the  abbreviated  title  of  the  unit? 

iUhat  is  the  abbreviation  (Unit  Designator  Code)  of  this  neu  unit? 
Uhat  is  the  postal  address  of  this  unit? 


h 

Uhat  is  the  on  base  telephone  extension  to  contact  this  unit? 


Figure  UM-12.  Add  Establishment  Unit  Screen 


Uelcone  to  the 
Establishnent  Table 
Add  Nodule 

Please  add  the  details  about  a  neu  establishnent  table. 


Establishnent  Table  File  Reference: 

} 

lEstablishnent  Unit  that  this  table  applies  to: 

!0ate  fron  uhich  this  table  uill  be  effective:  /  / 

’Date  the  establishnent  uas  created:  /  /  (default  is  today) 
Current  Anendnent  Nunber  for  table:  6 

Date  the  establishnent  table  uas  last  anended :13/B7/3B  (default  is 
Establishnent  Utilisation  Paraneter;  6.0  todag) 


Figure  UI4-13.  Add  Establishment  Table  Screen 
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The  Establishment  Unit  is  the  unit  responsible  for  managing 
theestabl i shment .  This  would  normally  be  a  Supply  Support  squadron  or 
Base  Squadron  that  has  an  RMS. 

All  dates  are  in  day /month/year  format.  The  with-effect  date, 
creation,  and  amendment  dates  for  the  table  are  set  at  today's  date  v;hen 
you  are  adding  a  new  table.  You  may  amend  these  to  other  valid  dates  if 
you  wish. 

The  current  amendment  number  is  set  to  0  when  the  table  is 
created. 

The  establishment  utilization  parameter  is  set  to  0.8.  This  may 
be  adjusted  to  reflect  different  management  emphasis  on  utilization 
rates  for  vehicle  authorisations  allocated  to  this  table. 

When  you  have  completed  all  the  entries  and  are  satisfied  vhth 
your  input,  press  <Ctrl  W>.  If  you  wish  to  abort  the  add,  press  <Esc>. 

Creating  an  Establishment  Authority 

To  create  an  establishment  authority  or  line  on  an  Estaol i sronent 
Table,  you  require  information  about  who  will  be  responsible  for  the 
vehicle.  This  vras  normally  shown  as  an  annotation  to  the  old 
Establ i .shment  Tables.  If  this  Ctistcxner  Element  and  its  parent  unit  have 
not  been  loaded  into  the  Customer  Element  and  Customer  Unit  database  you 
will  need  to  complete  that  first.  Load  the  Customer  Unit  and  then  the 
Customer  Element  the  same  v;ay  as  described  for  Establishment  Tables. 

You  are  now  ready  to  proceed  with  adding  an  authority. 

Adding  an  Authority.  Once  you  select  "A”  in  the  Add  menu  you  vh  1 1 
see  the  follov/ing  screen  (Figure  UM-14).  "UE"  for  "Unit  Establishment" 
has  been  .set  as  a  default.  You  may  change  that  to  any  other  valid 
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Ue  leone  to  the 
Estdblishnent  Authority 
Add  Hodule 

Pledse  add  the  details  about  a  new  establ ishwent  authority. 


Type  of  Estdblishnent:  U£ 

Parent  Establishnent  Table  to  which  it  will  belong;  UE 
Role  Code  of  the  vehicle  to  be  established;  U 
Establishnent  Line  Nunber  :  1  (calculated  autonatical ly) 

Number  established:  1 

Customer  element  authorised  for  the  establishment: 

Remarks  about  the  establishment; 

Date  to  be  effective  from;  13/67/90 

Date  last  amended;  13/07/90 

Date  established:  13/87/9B  (today  for  add) 

Date  last  reviewed  by  DMOUT-flF;  13/07/90 
EUR  that  established  the  requirenent: 


Figure  UM-14.  Add  Establishment  Authority  Screen 


option.  If  you  provide  other  than  a  valid  type  of  establishment,  you 
will  receive  a  warning  and  may  select  from  a  pick-list  to  make  you 
entry. 

The  parent  establishment  table  must  exist  prior  to  completing  the 
next  step.  You  will  be  asked  to  input  its  value.  If  you  can't  recall, 
press  <Enter>.  You  will  receive  a  v/arning  and  may  select  from  the  pick- 
list  of  correct  values. 

The  role  code  can  be  selected  from  a  pick-list  in  a  similar  manner 
to  the  above  if  you  can't  recall  the  details  or  wi.sh  to  check  them. 

ESTAB  automatically  calculates  a  unique  Establishment  Line  Number 
for  that  vehicle  role  on  that  Establishment  Table. 
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"Nuinber  Established:"  allov;s  you  to  designate  the  number  of 
vehicles  established  for  use  by  the  customer  element  stated  on  the  next 
1  ine. 

You  are  allov/ed  to  make  remarks  of  up  to  30  characters  that  vhll 
be  stored  with  the  authority. 

All  date  fields  are  set  to  a  default  of  today's  date  during  the 
addition  of  authorities.  Adjust  these  dates  if  necessary. 

The  facility  exists  for  four  letter  reference  to  the  Establ isliment 
Vehicle  Request  that  led  to  the  establishment  of  the  authority. 

Removing  an  Establishment  Authority 

Removing  an  establishment  authority  is  easy.  Simply  choose  the 
Database  Ilaintenance  "Delete  Current  Data"  option.  Select  "Authority  or 
line"  and  you  vnll  be  presented  with  the  following  screen  (Figure  UM- 
15)  . 


Delete  Establ ishnent  Authority 

Please  choose  from  the  fol lowing; 
Return  to  i«ialn  wenu  Delete  records 


Figure  UI-I-lS.  Delete  Establishment  Authority  Screen 
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To  delete  records  select  "Delete  Records",  You  will  be  presented  v/ith  a 
pick- list.  Choose  the  record  using  the  cursor  (arrow)  keys  and  press 
<Enter>  to  select.  A  short  cut  to  finding  the  record  is  to  press  the 
first  letter  of  the  establishment  type.  The  screen  v/ill  scroll  to  place 
the  first  record  of  that  type  at  the  top  of  the  list.  This  may  save 
sane  keystrokes  and  time. 

Once  you  have  selected  a  record,  you  will  be  asked  to  confirm.  If 
you  vnsh  to  forget  this  selection,  select  "NO".  If  you  v/ish  to  carry 
out  the  deletion,  select  "Y"".'".  You  will  be  returned  to  the  delete 
menu.  To  delete  another  record  follov-/  the  above  steps.  To  exit,  either 
press  <Esc>  or  select,  "Return  to  Main  Menu". 

Editing  an  Authority  or  Table 

All  editing  procedures  in  ESTAB  are  similar.  Using  a  pick- list 
you  can  choose  the  record  to  edit.  Once  you  have  selected  the  record, 
you  will  be  presented  v/ith  a  screen  showing  the  current  values  of  the 
fields  in  that  record  (Figure  UI'l-lS). 

The  screen  v/ill  be  similar  to  an  add  screen  except  you  v/ill  not  be 
al laved  to  edit  the  information  (primary  keys)  used  to  identify  the 
record.  Once  you  have  made  the  necessary  amendments,  use  the  same 
procedure  as  v/ith  the  other  add  routines  to  save  your  work,  <Ctrl  V/>  to 
save  or,  <Esc>  to  exit. 

This  tutorial  v/as  aimed  at  providing  you  with  additional  guidance 
to  familiarise  you  with  the  features  of  ESTAB.  ESTAB  has  been  designed 
so  that  all  like  procedures  operate  in  a  similar  manner.  Mastering  the 
above  procedures  v/ill  put  you  well  on  the  v/ay  to  mastering  the  use  of 
ESTAB.  Good  luck! 
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Uelcone  to  the 
Establishnent  Authority 
Edit  Nodule 

Please  edit  details  about  TS  establisbnent  authority  line 
nunber  1  fron  table  UE14  for  Role  Code  UAft  . 


Hunber  established:  1 

Custoner  elenent  authorised  for  the  establishnent :  AHSESl 
Xenarks  about  the  establishnent: 

Date  to  be  effective  fron:  2d/QS/BQ 

Date  last  anended:  28/66/38 

Date  established:  28/65/98 

Date  last  reviewed  by  DMGUT-AF:  28/65/90 

EUR  that  established  the  requirenent: 


Figure  UM-16.  Editing  an  Establishment  Authority  Screen 


125 


Appendix  E:  MT  MIS  Entity  Relationship  Diagrams 

Figures  E-1  and  E-2  depict  entities  required  in  an  integrated  MT 
MIS.  For  reproduction  purposes  the  figures  were  separated  into  the 
those  entities  required  by  an  RMS  and  those  required  by  SG3.  The  RMS 
information  requirements  center  around  daily  operational  transactions 
while  SG3  interests  are  in  higher  level  aggregated  data. 


Figure  E-l.  Road  Movements  Section  Aspects  of  an  MT  MIS 
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Figure  E-2.  Support  Group  3  Aspects  of  an  f4IS 
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